THE NEXT PATIENTAI-driven health care intel

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.

  • Trunk · master line
  • Interchange · pull request, review → approval → merge
  • Return · next task boards from master
  • Buffer stop · parked lane
  • Worktree lines A, B

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.

Recorded in
workspace-model.html (visual-operating-system v1.3.2) · verified 6 Sep 2026
Meaning
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.

Item
Finding
Result
GitHub connector identity
Authenticated as racingwbcoder85 / [email protected]
Verified
Private repository access
racingwbcoder85/zts-workspace; default branch master; read, push, merge-capable admin permission
Verified
Canonical read
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.