The practical Codex operating model · verified 6 Sep 2026 · static snapshot
One project. Many finite tasks. One worktree per writing lane.
The project supplies the territory. A task owns one result. Its worktree isolates the files. GitHub reconciles completed work. Steve—not a conversation—controls approval and promotion.
Important correctionA task is not automatically a worktreeIt becomes an isolated file lane only when it is started in Worktree mode inside a local Git project.
Context travels through files, not through Steve’s memory.
Each layer has one job. When the layers are mixed, discussions become rules and local outputs disappear.
11 / The transit map · branches as lines
The project is the building; tasks are rooms
Master is the trunk line. Each worktree is its own line that leaves the depot, runs through its stations, and rejoins the trunk only at the pull-request interchange. The parked lane ends at a buffer stop. The dashed return is the rule that the next task boards from current master.
Map pans sideways on small screens; the stations below are the controls.
Local is the foreground for inspection and reconciliation; worktrees are independent production lanes
Use the local ZTS Workspace project for sustained work. Start a separate, clearly named task for each output. Use Worktree mode whenever that task writes repository files. Batch the local work into one reviewable pull request, approve the result, then merge. Start the next task from current master.
Territory
Local project · the shared operating territory
For TNP, the useful local project is the checked-out zts-workspace repository. It lets every new task discover the same GitHub-backed instructions and current-state files.
A task keeps its own conversation. It does not automatically inherit every other task’s transcript. Its durable context comes from the project files it reads.
A worktree is a second checkout of the same Git repository. Use one for each task that will change tracked files, especially when several tasks may run at once.
Reconciliation gate
Pull request · the reconciliation surface
When the task has a reviewable result, its changes move to a branch and PR. Conflicts are resolved here before anything becomes current.
After Steve approves and the PR merges, new tasks start from the latest master. Old candidate files and chat conclusions do not outrank it. A merged implementation may update current state; it does not make a brainstorm a decision. DECIDED.md changes only after explicit, scoped Steve approval.
The official operating recommendation is one distinct outcome per task—not one task per project.
What this model cannot do
Approve anything. Project instructions route the work; they do not invent policy.
What each layer means
Six layers, one job each
The official operating recommendation is one distinct outcome per task—not one task per project.
Project
The shared operating territory
For TNP, the useful local project is the checked-out zts-workspace repository. It lets every new task discover the same GitHub-backed instructions and current-state files. One project can hold TNP, Build, and other rooms because the repository already separates them.
Task / chat
One finite business outcome
A task keeps its own conversation. It does not automatically inherit every other task’s transcript. Its durable context comes from the project files it reads. Good: “TNP — assemble sample issue.” Bad: “Work on The Next Patient.”
Worktree
The private drafting room
A worktree is a second checkout of the same Git repository. Use one for each task that will change tracked files, especially when several tasks may run at once. It prevents file collisions; it does not create memory or authority.
Pull request
The reconciliation surface
When the task has a reviewable result, its changes move to a branch and PR. Conflicts are resolved here before anything becomes current. This replaces “close every chat before opening another” with controlled parallelism.
Master
The next task’s starting point
After Steve approves and the PR merges, new tasks start from the latest master. Old candidate files and chat conclusions do not outrank it. Latest means verified master plus live vendor state—not the newest filename.
Authority
Approval remains separate
A merged implementation may update current state. It does not make a brainstorm a decision. DECIDED.md changes only after explicit, scoped Steve approval. Project instructions route the work; they do not invent policy.
A normal TNP day
Three jobs can move without stepping on each other
Local is the foreground for inspection and reconciliation. Worktrees are independent production lanes.
EnvironmentPurpose
Worktree AProduce the next issueUses the verified V5.6 line; stops before send.
Worktree BVerify checkoutTests the public-to-paid path without changing billing identity.
Worktree CX scoutParked because the Grok/X account is unresolved.
Steve’s foregroundReview + direction
Short reviewApprove one private testAuthorization applies only to the named issue and recipient.
Commercial reviewInspect checkout proofEvidence returns to its task; no silent rules.
As desiredChoose the next constraintThe workboard recommends by time and mental mode.
ReconciliationGitHub
PR AIssue run evidenceReview → approval → merge.
PR BCheckout evidenceReview → approval → merge.
No PRNo work performedThe hold remains visible without a workaround.
Live setup audit
One connection is ready; one structural correction remains
Checked 6 Sep 2026 in the source page. Recheck before relying on these as future live facts.
README.md fetched successfully from master during this audit
Verified
Local zts-workspace project
No saved local Git project currently points at a cloned zts-workspace checkout
Correction
This visual-board folder
The audited Fable/Claude V2 package is the current v2.1.0 production reference at the TNP review sites.
Production v2.1.0
Approval behavior
This task uses automatic review. Worktrees reduce mechanical remote writes, but external connector changes and Computer Use can still require approval.
Optimized
Instruction robustness
Check actual repository read capability; do not depend on one legacy internal tool prefix
Corrected model
The operating rule
Use the local ZTS Workspace project for sustained work. Start a separate, clearly named task for each output. Use Worktree mode whenever that task writes repository files. Batch the local work into one reviewable pull request, approve the result, then merge. Start the next task from current master.