Furth FortuneM9 reference

Assurance fabric / System overview

Coordinated Delivery

Isolated work with named ownership and proof

Each change has an owner, an isolated work area, required checks, and a verified merge to the shared main line. The same process applies to human and assisted work.

Inside the system

Architecture plates

Each plate preserves the internal layout, paths, boundaries, and highlighted decisions. Use the short label first, then follow the lines through the system.

Plate 01

One worktree per task, and you land it yourself

start · the landing loop · confirm and clean up

1 · START: YOUR OWN WORKTREE, OFF THE LATEST MAIN git fetch originorigin/main is the base git worktree add -bagent/<slug> in ../mtk-wt/<slug> coordinator claimexit 75 = another agent owns it commit on your branchgit add -A is safe here 2 · LAND: THE LOOP THAT RUNS UNTIL IT STICKS git fetch originmain may have movedwhile you verified git rebaseonto origin/mainkeep BOTH intents re-verify GREENcompile plus thegates you touched refresh artifactsLAST, and on everyloop iteration push HEAD:mainfast-forwards mainto your work PUSH REJECTED · main moved while you verified · run the loop again 3 · CONFIRM IT LANDED, THEN CLEAN UP merge-base --is-ancestoryour top commit vs origin/main git worktree removefrom the primary checkout git branch -D agent/<slug>only after LANDED is proved coordinator releasein the same cleanup step DONE MEANS LANDED A task is done when its commits are ancestors of origin/main, and when you verified that yourself. Landing is never a question for the user. NOT A RESTING STATE A branch or a worktree with commits that are not on origin/main holds unfinished work. If you find one, claim it first, then land it. Never prune it.
Plate 02

What this model replaced, and the backstop that proves it

the two old failures · the index rule · the stranded-work backstop

WHAT THIS MODEL REPLACED one shared main worktree one index for every agent staged deletions of landed work one agent sweeps another's stage just make a branch isolation with no landing rule a branch that nobody merges the work is simply lost isolated worktree, and you land it yourself The index, the tree and the branch are private, so no agent can sweep another agent's staged files. Landing is part of the task. A task is not done until its commits sit on origin/main and you have verified that. Separate machines already have separate clones, and land the same way. THE INDEX RULE THAT KEEPS THE OLD FAILURE OUT never sync by pointing the index at a ref git reset / restore / checkout <ref> -- <paths> strands landed files as staged deletions THE TELL a D for a file you did not delete, still present on disk re-add the path never commit the deletion THE BACKSTOP · agent-sweep CLASSIFIES EVERY BRANCH AND WORKTREE worktree list -z plus for-each-ref over every local branch merge-base --is-ancestor X against a freshly fetched origin/main LANDED · prunable UNLANDED · reported EVERY AMBIGUITY resolves to UNLANDED: a false LANDED loses work
Plate 03

The claim: a collision becomes visible in seconds

the identity chain · what claim returns · the TTL and the sweep

CLAIM BEFORE YOU WORK agent-coordinator claim --agent <id> --note <text> --ttl <s> <branch-or-worktree-slug> IDENTITY DECIDES WHO MAY RELEASE 1 · --agent <id> on the command line 2 · AGENT_NAME 3 · CODEX_THREAD_ID 4 · none of these, so REFUSE user@host is never a fallback every co-located agent shares it, so any of them could release any other agent's claim WHAT claim RETURNS 0 · claimed the key is yours; the release line prints 0 · refreshed the same claimant resets the TTL in place 75 · another agent owns it prints the owner, the note and the age it never blocks: go find other work 2 · refused, and named a second key an unknown option a flag with no value LIVENESS IS THE TTL ALONE A claim outlives the shell that took it, because an agent claims from one command and releases from another. The recorded pid is informational, and usually dead. ttl_seconds 14400 four hours by default; --ttl sets it an expired claim is removed on sight claims · status · clean-stale both listings mark an expired claim clean-stale removes it, and removes a stale scope lock in the same pass WHERE A CLAIM LIVES, AND WHY THAT IS THE RIGHT SCOPE <git common dir>/agent-coordinator/claims/<key>.claim format=agent-coordinator-claim-v1 key · claimant · owner · pid · started_epoch ttl_seconds · note ONE STATE SET PER MACHINE, NOT PER WORKTREE The problem is two agents on ONE box, invisible to each other. Every worktree shares one git common dir, so config stays per tree and state stays per machine.
Plate 04

Four scopes, and the argument split that guards them

the four scopes · the -- split · the busy signal and the reclaim rule

FOUR SCOPES · ONE LOCK FILE EACH repostale 7,200 s · 59 tools · 1,769 leaves native-buildstale 3,600 s · 53 tools · 2 leaves trident-runtimestale 3,600 s · 12 tools · 22 leaves external-toolsstale 3,600 s · 1 tool · no leaf THE CHILD INHERITS THE SCOPE GATE_SCHEDULER_INHERITED_COORDINATOR_SCOPE carries the acquired scope down, so a sibling does not reacquire its parent's lock run · THE -- SPLIT IS THE CONTRACT before -- the coordinator's own flags: --wait · --poll <s> · --agent <id> plus exactly one tool id after -- reaches the wrapped command verbatim, flag-shaped or not an unknown token before -- is refused BY NAME, never forwarded to the tool as a positional argument A forwarded --wait lands in the driver's second argument, and every gate id then reads as ambiguous. WHEN ANOTHER AGENT HOLDS IT exit 75 · busy prints scope, tool, owner, pid, age the command, and the log path plus an ETA when history exists RECLAIM · TWO GROUNDS, IN ORDER a pid that names no live process is decisive at once stale_after_seconds is only the fallback when the host cannot say A live owner keeps its scope past the window. A run that dies cannot lock the machine against its own retry. Use --wait to queue behind the owner instead of returning. HOST ROUTE · DECLARED, NEVER GUESSED command_windows · 40 tools pins native Git Bash, because CreateProcess searches System32 first, where bash.exe launches WSL windows_route=wsl · 8 tools the script genuinely needs Linux: strace, POSIX sockets, mbedTLS. the reason field is mandatory. platforms=windows · 53 tools an off-platform tool is refused BEFORE the lock: no lease, no log, and no history row
Plate 05

Landing into a main branch that keeps moving

four symptoms · four verdicts · what your own landing does to a run in flight

READ A FAILURE WHILE main CHURNS a compile error that MOVES between rebases the same file fails differently after each rebase trident_rt.c and the hosts churn hardest TRANSIENT · re-verify, do not repair it another agent's landed refactor is converging re-verify against the rebased tree, then retry FAILS in an aggregate, PASSES standalone the same leaf, the same tree, two results a content-hash cache can serve a torn binary RACE · re-run it a concurrency artifact, and not your bug remove the cached binary, rebuild clean, retry reproduces standalone, every time isolated from the aggregate and from the cache the standalone re-run is the arbiter, both ways REAL · it is yours to fix a consistent standalone failure is a defect landing broken work is worse than landing late unknown function 'x.y' a verb the tree has, and your binary does not you built that binary before the verb landed STALE BINARY · rebuild confirm the rebased tree compiles first then rebuild from it and re-run YOUR LANDING IS ANOTHER AGENT'S CHURN you push to main tracked files move under a profile run already in flight workspace snapshot taken when the plan is built and verified again at the end one leaf's inputs changed · invalidated-by-churn typed apart from pass and fail; no green profile HEAD or the manifest moved · exit 76 RESTART-REQUIRED: no verdict for any gate in the run

Key parts

What the system does

These are the main boundaries, inputs, outputs, and failure rules. The examples show a specific use of each part.

Isolated change scope

Each task works in its own controlled copy until it is ready to integrate. One effort cannot quietly overwrite another.

Specific example

Two teams can update separate mission services at the same time without sharing an unsafe working state.

Visible ownership

A task is claimed and associated with a clear purpose. Conflicting work is found early.

Specific example

A program lead can see that an interface change already has an owner before assigning duplicate effort.

Verified integration

The task owner must bring the change into the approved main line and confirm the result. Work is not treated as complete while stranded elsewhere.

Specific example

An assisted coding task remains tied to a responsible owner, evidence, and an integrated source record.

Uses

Example uses

Pilot questions

What the team must decide

How task ownership is recorded

Which checks are required before integration

How assisted work is reviewed and attributed

Request a technical briefing

Connected references

Assurance fabric Evidence and Verification Open reference Assurance fabric Release Assurance Open reference Assurance fabric System Boundaries Open reference
Return to the M9 reference library