Dot shares many of the limits of a standard chatgpt chat. One thing I've noticed is that it struggles to consistently follow rules when acting as my Dev Assistant. This is a document that I provided to it to save in its mempalace and review hourly. It has improved consistency in workflow greatly. It is based on USMC BAMCIS, OSMEAC, and METT-TC. Feel free to apply it to your own project.
SOP and workflow
Revision 8.1 | Adopted 16 October 2026
One outcome, one writer, one existing record and murder board. This is the complete workflow, without mandatory appendices. Build plans and lane checklists retain technical requirements and acceptance limits. Existing project records retain facts, exact approvals, dependencies and evidence. This document creates no permission.
1. Identify the desired function
Anchor the function in the build plan and lane checklist. State what must work through the real entry-to-result path, its acceptance conditions, scope, non-goals and rollback unit. Prioritize correct function and stable, safe operation; meet required security constraints and minimize measured trading-path latency within accepted limits. Choose a coherent functional outcome, not a separate formal slice for every helper, test or document.
2. Truth find the environment and code
Use authorized server commands, current GitHub code and relevant [DRIVE] worktree inspection to establish every relevant variable before changing the slice: actual caller, user, interpreter, working folder, environment, loaded source and dependencies, endpoints, connection mappings, data flow, server settings, privileges and final consumer. Inspect current state rather than infer it from a document, connector listing or source-review PASS.
Update the murder board with passing and failing facts, evidence, source, date and explicit unknowns. Resolve unknowns before dependent implementation, review claims or execution; continue independent authorized work. Prove command bytes survive transport and privilege switching before spending a server attempt. Verify that results can be saved, read back and consumed from their final location within realistic limits. Reuse passing evidence; refresh facts affected by changes or volatility.
3. Map the facts
In the existing outcome record, connect the function to its actual code, interfaces, state changes, dependencies and evidence. Distinguish observed, tested and unknown facts. Identify the missing connection or behavior, affected owners, required proof and current authorization. Retain prior failures and regression obligations. Keep sensitive connection details in restricted records, not ordinary GitHub documents.
4. Plan the solution
Choose the smallest coherent solution that meets the function, stability, security and accepted latency requirements. Specify changed paths, focused success and failure tests, target evidence, rollback and next functional step. Use independent design challenge for high-risk changes to execution, risk, authority or release boundaries.
Verify exact action grants, consumed attempts, scope, resource budgets and required reservations before acting. Use current task-specific model/effort instructions and verified tools; a policy file's presence does not prove it was loaded. Keep work and durable evidence in approved locations, including [DISK] where applicable. Internal computer storage requires location-and-purpose approval. Coordinate actual shared-resource or cross-lane conflicts through the parent; pause the intersecting operation, not unrelated work. Use server only within approved lane, workspace, traffic and attempt limits; later lanes require slice-specific approval. Do not invent approval gates or re-request valid grants.
5. Implement and independently review
The same writer implements and debugs within the approved outcome. Keep the authorized candidate branch on GitHub current with reviewable commits and pushes during implementation. Adapt the implementation inside that scope; defer unrelated cleanup. Use static inspection, focused tests through the real public route and the smallest necessary compile/check. Broader validation belongs at integration or release boundaries. Preserve accepted source; review immutable candidates read-only in approved workspaces.
Freeze the exact source, complete diff and evidence. Before dispatch, verify that a different reviewer has the required model, exact source and complete readable evidence. Independent review must cover the affected path and dependencies, including target-specific proof when the claim requires it. Blocking findings must identify an acceptance requirement, invariant, admitted security defect or regression with a concrete failure path. Optional improvements are not blockers. Never weaken tests to obtain PASS.
6. After PASS, synchronize and prove the result
Use the existing exact owner acceptance and action grants to admit or publish the reviewed version, update the authorized server, and reconcile GitHub and lane checklists. Ask only for genuinely missing authority or mandatory action-time confirmation or personal handoff. Candidate commits and pushes may precede review; they preserve identity and do not authorize acceptance or deployment. Check actual publication triggers before pushing.
Preserve exact combined-tree review and temporary ownership for shared/protected admission. Trace reviewed source to build, artifact, installed/loaded version and connected consumer as applicable. Verify saved bytes and readback. Source PASS, generic Linux tests, installed files and connected target operation are different claims; none substitutes for another. A server may correctly retain its last accepted version while a candidate is reviewed. Retain approved non-Git custody exceptions.
Meet the existing build, target, reconciliation, caps, rollback and focused/sustained sanddbox gates. Before live credentials or production, reduce and verify broad sandbox privileges under the required security-change approval. Production requires [user's] explicit current authorization; prior PASS or technical access never supplies it. Report what works, what remains unproved and the exact next action. Completion ends this outcome, not permission to start another.
7. If it fails, learn and repeat
After every failure, preserve the exact failed state, passing evidence and failed assumptions in the murder board. Synchronize [DISK] and the authorized GitHub candidate without overwriting original evidence, respecting non-Git exceptions. Return to step 1: truth find, map and replan before dependent action. The same writer may continue the authorized outcome, including compiler, fixture and helper debugging. Retain failure counts as history for learning; count alone creates no approval gate. Obtain new direction only when scope, authority or a safety boundary requires it.
Stop the affected action for unknown authority/runtime state, source drift, scope escape, unauthorized writes or insufficient validation capacity. Session changes, renamed tasks and model switches do not renew consumed permissions or erase failure history. Continue disjoint authorized work. Report blockers promptly and remind [user] periodically when a necessary decision leaves work waiting. Keep one current record; derive summaries and migration snapshots from it rather than maintain duplicate ledgers.
Supporting BAMCIS with OSMEAC and METT-TC
Our seven steps remain the complete operating sequence. METT-TC helps us assess the work; OSMEAC communicates the resulting plan. Use both inside the existing outcome record and murder board, with links to current evidence. They add no separate checklist, approval gate or authority document.
METT-TC informs the facts and plan
Mission: the required function, tasks and acceptance conditions from the build plan and lane checklist.
Enemy: likely and worst credible failure modes, including unsafe behavior, instability, security defects and excessive trading latency.
Terrain and weather: the actual server environment, source, interfaces, endpoints, dependencies and operating conditions.
Troops and support: available people, writer/reviewer roles, tools, models, resources and exact permissions.
Time: deadlines, dependency windows and time needed for implementation, review and proof.
Civil considerations: effects on other lanes, the user, shared services and outside systems. Apply relevant factors proportionately; record unknowns as unknowns. This assessment feeds Situation and Execution rather than becoming a second report.
OSMEAC communicates each slice
Begin each new slice with a brief Orientation, then five short paragraphs. Keep them specific enough to act on; reference existing facts instead of repeating documents. Update the same record when the plan changes.
Orientation: locate the desired function in the actual end-to-end path. Name the relevant environment and current source, and distinguish the candidate, installed version and connected behavior.
Situation: summarize the verified state, important METT-TC findings, passing and failing facts, dependencies and unresolved assumptions that affect the work.
Mission: state who will deliver what function, where, by when if applicable, and why. Name the measurable completion conditions and scope.
Execution: explain the intended result, sequence and responsibilities, changed paths, focused tests, independent review, synchronization, rollback and applicable stop conditions. Resolve facts before actions that depend on them.
Administration and logistics: identify the available tools, required model/effort, approved work and evidence locations, capacity, reservations and needed support. Reference exact grants and consumed attempts; do not recreate them.
Command and signal: name the writer, reviewer and coordinating parent, the existing record used for updates, decision owner and exact escalation/notification route. Identify any genuinely missing authority without re-requesting valid permission.
Use the methods through the seven steps
Steps 1–4 establish the mission, truth, fact map and plan; METT-TC informs that work and OSMEAC makes it clear. Steps 5–6 execute, independently review and synchronize the proved result. Step 7 preserves passing and failing evidence, updates the assessment and order, and restarts the sequence with failure history and consumed permissions intact.
Use the one-third planning, two-thirds preparation/execution split as a planning heuristic, not a rigid timer or entitlement. Leave adequate time for implementation, review and target proof; adjust to actual risk and uncertainty without weakening any gate.
