Furth FortuneEngineering reference
TECHNICAL DOCUMENTATION

2027 · MerTek technology

On this page

Engineering reference / System overview

Coordinated Delivery

Parallel changes with an owner and proof of landing

Every change has a claimed owner, its own worktree, the checks its files need, and a verified landing on main. A change is done only when its commit is an ancestor of main. People and AI-assisted lanes follow the same rules and leave the same record.

Worked example

Two changes to the payroll app on one Thursday

The Brookfield clinic group pays 900 staff every other Friday. On Thursday a payroll engineer fixes a shift-rounding bug while an AI-assisted lane adds an overtime export, and both touch the same payroll app. Friday's 06:00 run builds from whatever is on main.

  1. Claim before editing. A work claim is one commit on main that marks the item active and names the worktree, the host and the model doing it. It lands before any code, so a second lane reading the same item sees it taken and picks other work.

    {
  "item": "Overtime export for the Friday payroll run",
  "state": "ACTIVE: payroll-overtime@ops-build-02@assistant-lane",
  "claimedAt": "2026-10-15T13:05:00Z",
  "checks": ["payroll-suite-test"],
  "landed": null
}

  2. Work in an isolated worktree. Each lane takes its own worktree from main, so a half-finished edit in one lane never enters another lane's commit or test run. Add files by path, never by sweep, so a commit holds only work its owner can account for.

    git fetch origin
git worktree add .worktrees/payroll-overtime origin/main
cd .worktrees/payroll-overtime

# edit, then add files by path
git add payroll/a/export.tri payroll/a/_test/overtime.tri
git commit -m "Export overtime hours for the Friday run"

  3. Run the checks the changed files need, on the rebased tip. Testing after the rebase means the verdict grades the exact tree being pushed. Exit status is the verdict, so the lane reads Ninja's own status and never a filtered pipe.

    git fetch origin
git rebase origin/main
ninja -k 0 payroll-suite-test
git push origin HEAD:main

  4. A moved main means rebase and retry, never force. The engineer's rounding fix landed first, so the lane's push is rejected. The lane fetches, rebases and pushes again; a conflict-free rebase carries the earlier verdict, so no second test run is needed.

    $ git push origin HEAD:main
To git.brookfield.example:payroll.git
 ! [rejected]        HEAD -> main (fetch first)
error: failed to push some refs to 'git.brookfield.example:payroll.git'

$ git fetch origin
$ git rebase origin/main          # read its exit status on its own
Successfully rebased and updated detached HEAD.
$ git push origin HEAD:main       # conflict-free: the verdict carries

  5. Prove the landing. The lane fetches and checks that its final commit is an ancestor of main, then reports that commit. Work that sits on a branch or in a worktree is undelivered, however green it is.

    git fetch origin
sha=$(git rev-parse HEAD)
git merge-base --is-ancestor "$sha" origin/main && echo "landed $sha"
# Close with the commit and this check. A summary that says "done"
# and names no commit is a claim nobody can check.
What happened

Both changes reached main by 15:30 with their checks green on the rebased tip. The rejected push cost one fetch and one rebase, and no second test run, because the rebase was clean. Friday's run built both changes, and each commit named its owner and the lanes it passed.

System diagram

A change is not done until it lands

Ownership, isolation, checks, and integration are visible steps with recorded results.

  1. Claim owner + task scope
  2. Isolated work short-lived worktree
  3. Verify affected gates pass
  4. Land merge to main + prove ancestor

Inside the system

How the parts work together

Follow the data, decisions, and access boundaries. Each diagram explains a concept used by applications.

Map 01

Integration backstop

A change counts as finished only when its commit is on the shared main line and the ancestor check proves it.

  1. Task branch unique commits
  2. Verification required checks
  3. Main line integrated commit
  4. Ancestor proof landing confirmed
Map 02

Claim collision

Two tasks that target the same scope learn about the conflict before editing.

  1. Task A claims scope
  2. Coordinator records owner
  3. Task B same scope
  4. Immediate refusal duplicate work avoided
Map 03

Four coordinated scopes

Build, test, repository, and task ownership use separate locks and argument boundaries.

  1. Task claim who owns work
  2. Repository scope branch + worktree
  3. Gate lane shared machine
  4. Tool arguments safe command split
Map 04

Moving-main landing loop

A rejected push means fetch, rebase, recheck what the resolved files need, and push again, never force.

  1. Fetch latest main
  2. Rebase keep both intents
  3. Re-verify affected gates
  4. Push fast-forward only
  5. Retry if moved never force

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.

A claimed owner

A work claim is a commit on main that marks one item active and names the worktree, host and model doing it. It lands before any code. A lane that stops early lands its findings first, then releases the claim.

For example

Two lanes about to start the same interface change both read the item; the second sees the first claim and picks other work.

An isolated worktree

Each change gets its own worktree from main. A lane never uses the shared stash, never resets a file it did not change, and adds files by path. A worktree is removed only after its work is on main.

For example

A rebase in one lane cannot erase another lane's uncommitted edit, because the two never share a working tree.

A verified landing

Fetch, rebase, test the rebased tip, push without force, then prove the commit is an ancestor of main. A rejected push means fetch, rebase and push again. A hook refuses any push made from the middle of a rebase.

For example

A lane that chains a push behind a conflicted rebase is stopped before half its commits land on main.

Code

Coordinated Delivery in code

Each example is short and complete enough to read on its own. Hover a dotted word for its definition.

Shell

The push guard

A pipeline reports its last command's status, so a conflicted rebase can look like success. The pre-push hook refuses the operation itself, whatever the commits contain.

$ git rebase origin/main | tail -1 && git push origin HEAD:main
CONFLICT (content): Merge conflict in payroll/a/export.tri
push-guard: refusing HEAD -> refs/heads/main
push-guard: in progress: rebase-merge
push-guard: HEAD is <sha>, a state this operation has not
push-guard: finished writing. Pushing it publishes the part it
push-guard: replayed and leaves the rest unlanded.
push-guard: Finish the operation, or abort it, then gate and
push-guard: push the completed series.
Shell

Lanes on one host

The lane reader lists every worktree on a host, what it holds that main does not, and whether a claim names it. Only clean licenses removal.

LANE              UNLANDED  UNCOMMITTED  CLAIM                    VERDICT
old-rate-fix             3            1  -                        ORPHAN
payroll-overtime         2            0  overtime-export ACTIVE   holding
shift-rounding           0            0  -                        clean

1 orphan: unlanded commits with no claim naming them.
ORPHAN = NOT removable: unlanded commits nothing claims; read it, land what is proved, record what is not, then drop it.
clean = removable, because nothing is unlanded and nothing is uncommitted.
holding = NOT removable: unlanded commits, and the claim says whose.
Shell

Which checks a change needs

A file change decides which checks run, never an event. A clean rebase or a rejected push needs nothing new.

# you changed                     run
# a node's .c, .h or .def         ninja -k 0 <node>-test
# an app's .tri or its _test/     ninja -k 0 payroll-suite-test
# a doc                           ninja -k 0 doc-links-test
# a claim commit only             the work-index lane alone
#
# after your verdict              needs
# another commit before testing   nothing yet; test once, at the end
# a conflict-free rebase          nothing
# a resolved conflict             the lanes for the files you resolved
Shell

Read the verdict from the run, never from a pipe

A pipeline reports its last command's status, so a red run piped into tail reads green. Keep the whole log and the run's own exit status, then read the file.

# Wrong: this reports tail's status, so a failed lane reads as success.
ninja -k 0 payroll-suite-test | tail -5

# Right: keep the whole run and its own status.
ninja -k 0 payroll-suite-test > run.log 2>&1
echo "exit $?" >> run.log
Shell

Release a lane with its findings first

Unproved code is cheap to write again; what the lane learned is not. A lane that stops lands its findings, then frees the claim, so the next owner reads them on main.

# 1. the findings: decisions, measured figures and the next step
git add payroll/docs/overtime-export.md
git commit -m "Record overtime export findings and next step"
# 2. the release: the item's state cell goes back to READY
git add docs/work-index.md
git commit -m "Release overtime export claim"
git fetch origin
git rebase origin/main
git push origin HEAD:main

Uses

Example uses

  • AI-assisted changes with a named, accountable owner
  • Several teams working one codebase in parallel
  • Audit trails that tie each change to its checks

Review questions

What the team must decide

How work items are claimed and released

Which checks each kind of file change needs before landing

How AI-assisted work is reviewed and attributed

Contact us

Connected references

Engineering reference Evidence and Verification Open reference Engineering reference Release Assurance Open reference Engineering reference System Boundaries Open reference
Return to the MTK reference library
FURTH FORTUNE / ENGINEERING REFERENCEBack to top ↑