Mission Transaction Work Spine

The riskiest moment in agentic code work is the one that feels safest. An agent runs a few checks, sees no errors, and concludes its work is finished and committed. The riskiest moment in agentic code work is the one that feels safest. An agent runs a few checks, sees no errors, and concludes its work is finished and committed. Those are two different facts. A clean preflight describes the state of the checks. It says nothing about whether a competing claim already owns the same file, whether the branch moved underneath the agent, or whether the commit ever landed.

mission_transaction_work_spine is a fixture that replays a fixed set of work-landing situations against a toy repository and records, for each one, whether the change would be allowed to land or would be blocked. mission_transaction_work_spine is a fixture that replays a fixed set of work-landing situations against a toy repository and records, for each one, whether the change would be allowed to land or would be blocked. It reads recorded inputs, recomputes each decision from copied internal control source code, and writes one result record per situation that says exactly why the situation was permitted or refused.

Recompute decisions instead of trusting labels

The design choice that matters is that the validator refuses to trust the labels baked into its own inputs. The design choice that matters is that the validator refuses to trust the labels baked into its own inputs. It then perturbs the input one field at a time and requires the decision to move.

Purpose

A loose check passes whenever its inputs carry the right labels. That is the failure this component is built against. A loose check passes whenever its inputs carry the right labels. That is the failure this component is built against. Agentic work fails most often at transaction boundaries, not at isolated syntax errors: a clean preflight read as a landed commit, a competing claim on the same file ignored, a claim whose expected parent no longer matches the repository, a downstream item marked ready without its hard dependency, a dirty tree used to justify a broad commit with no operator intent, or a result record that smuggles private ledger bodies into a public artifact.

The single question the fixture answers is narrow. What evidence has to hold before a unit of work is allowed to land, and is that evidence checkable rather than asserted? The single question the fixture answers is narrow. What evidence has to hold before a unit of work is allowed to land, and is that evidence checkable rather than asserted? A cold reader can open the inputs, the copied source bodies that implement the checks, and the result records, and see which decision came from which check.

How it works

The module has two entry paths, selected by subcommand. run validates the first-wave replay fixture. The module has two entry paths, selected by subcommand. run validates the first-wave replay fixture. run_mission_transaction_bundle validates the exported bundle of copied source modules. Both write metadata-only result records.

run loads the fixture payloads, scans every input file for forbidden private classes, then calls one validator per concern and merges their findings. run loads the fixture payloads, scans every input file for forbidden private classes, then calls one validator per concern and merges their findings. Status is pass only when no expected negative case is missing, the secret scan passes, and the real-snapshot replay passes. The validators it calls carry the mechanism.

validate_claim_preflight reads the active claims and the toy repository state. It walks the claims, records the first owner of each path, and emits SAME_PATH_CLAIM_CONFLICT when a second active claim wants a path that is already owned. validate_claim_preflight reads the active claims and the toy repository state. It walks the claims, records the first owner of each path, and emits SAME_PATH_CLAIM_CONFLICT when a second active claim wants a path that is already owned. It compares each claim's expected_parent_sha against the current parent in the repository state and emits EXPECTED_PARENT_MISMATCH when they differ. A claim with no owned path emits MISSING_OWNED_PATH.

validate_checkpoint_lane_policy reads a set of commit-lane cases. For each case it computes the recommended lane and compares it to the selected lane. validate_checkpoint_lane_policy reads a set of commit-lane cases. For each case it computes the recommended lane and compares it to the selected lane. A broad_checkpoint lane without operator_authorized_broad_checkpoint set to true emits CHECKPOINT_BROAD_AUTH_REQUIRED. A suspected secret not routed to the hard-stop lane emits CHECKPOINT_SECRET_REQUIRES_HARD_STOP. A dirty tree with isolated owned paths must not block a scoped commit, so a case that treats it as a scoped blocker emits CHECKPOINT_DIRTY_TREE_NOT_SCOPED_BLOCKER. A case with no selected lane emits CHECKPOINT_LANE_DECISION_REQUIRED.

validate_real_active_claims_snapshot is the discriminating check

**validate_real_active_claims_snapshot is the discriminating check. It then calls active_claim_collisions_for_paths three times: on the real status, on a status mutated to add a same-path conflict, and on a status mutated to add a disjoint-path claim. The real status must return no collision for the requested path, the same-path mutation must return one, and the disjoint mutation must return none. It also mutates the expected parent and the checkpoint lane row and requires each mutation to block while the equal-parent and disjoint cases stay clear. Only when the good case passes, every mutation blocks, every clear case clears, the source hash binds, and the session heartbeat binds does it award the R3 rung public_safe_real_work_ledger_session_snapshot_replay. Otherwise it falls to R2 or R1.

run_mission_transaction_bundle validates copied control source. The four import validators (validate_task_ledger_source_import, validate_work_ledger_source_import, validate_checkpoint_source_import, validate_mission_control_source_import) each read a source-module manifest and a runtime contract, check that the manifest declares exactly the expected module ids and count, then for each module confirm the copied file exists, contains its required internal control anchor strings, matches the manifest sha256, and carries classification: copied_non_secret_macro_body with body_in_receipt: false. run_mission_transaction_bundle validates copied control source. The four import validators (validate_task_ledger_source_import, validate_work_ledger_source_import, validate_checkpoint_source_import, validate_mission_control_source_import) each read a source-module manifest and a runtime contract, check that the manifest declares exactly the expected module ids and count, then for each module confirm the copied file exists, contains its required internal control anchor strings, matches the manifest sha256, and carries classification: copied_non_secret_macro_body with body_in_receipt: false. The bundle path also requires the real claims snapshot to be present and to pass.

Nine metadata-only transaction records

write_receipts writes the nine result records for a fixture run (preflight, dependency-blocked, work-landing attempt, claim preflight, scoped mutation, checkpoint lane, completion projection, dependency-unlock scheduler, reconcile plan). write_receipts writes the nine result records for a fixture run (preflight, dependency-blocked, work-landing attempt, claim preflight, scoped mutation, checkpoint lane, completion projection, dependency-unlock scheduler, reconcile plan). Each record carries a schema version, refs, counts, hashes, verdicts, and body_in_receipt: false. Source bodies live only in the exported bundle's source_modules/ tree; they never enter a result record.

flowchart TD Fixture["First-wave fixture claims, deps, lane cases, snapshot"] Bundle["Exported bundle copied source modules"] Preflight["validate_claim_preflight + checkpoint lane policy"] Replay["validate_real_active_claims_snapshot runtime-rebuilt snapshot + perturbations"] Imports["four source-import validators manifest, anchors, sha256"] Records["metadata-only result records refs, hashes, verdicts, limits"] Fixture --> Preflight Fixture --> Replay Bundle --> Imports Preflight --> Records Replay --> Records Imports --> Records

Negative cases

The positive claim is not that the fixture passes. It is that the fixture accepts good evidence and rejects targeted one-field perturbations. The positive claim is not that the fixture passes. It is that the fixture accepts good evidence and rejects targeted one-field perturbations. Fourteen named negative cases are required, each bound to its error code:

competing_claim_and_stale_parent must observe both SAME_PATH_CLAIM_CONFLICT and EXPECTED_PARENT_MISMATCH

**competing_claim_and_stale_parent must observe both SAME_PATH_CLAIM_CONFLICT and EXPECTED_PARENT_MISMATCH. mission_claim_missing_owned_path observes MISSING_OWNED_PATH. scoped_commit_receipt_claims_global_authority observes SCOPED_RECEIPT_AUTHORITY_UPGRADE. mission_fixture_private_task_ledger_body observes LIVE_TASK_LEDGER_BODY_IN_FIXTURE. clean_preflight_overclaims_landing_complete observes PREFLIGHT_PASS_OVERCLAIMS_WORK_LANDED. dependency_unlock_without_resolution_receipt observes DANGLING_DEPENDENCY_REF and ready_workitem_with_unsatisfied_hard_dep observes READY_WITH_INCOMPLETE_HARD_DEP. The four checkpoint-lane cases (broad_checkpoint_without_operator_authorization, suspected_secret_without_hard_stop, dirty_tree_blocks_scoped_lane, missing_selected_lane_for_state) observe the lane error codes above. A run is blocked if any of these expected cases is not observed.

Prior Art Grounding

This is the mission-transaction member of a small family of work-landing fixtures. Its closest sibling is durable_agent_work_landing_replay, which checks recorded landing rows, validation-before-commit ordering, HEAD movement, blocker capture, and completion evidence without running live git. This is the mission-transaction member of a small family of work-landing fixtures. Its closest sibling is durable_agent_work_landing_replay, which checks recorded landing rows, validation-before-commit ordering, HEAD movement, blocker capture, and completion evidence without running live git. This module narrows that pattern to the transaction preflight and the work-ledger claims membrane: same-path conflicts, expected-parent mismatches, checkpoint-lane selection, dependency unlocks, and session finalisation. The lineage is transactional-integrity engineering, specifically compare-and-set on a parent commit and single-writer path claims. There is no external citation to invent here; the pattern is standard optimistic-concurrency control applied to a repo.

Validation Result record Path

PYTHONPATH=src python3 -m microcosm_core.organs.mission_transaction_work_spine run \
  --input fixtures/first_wave/mission_transaction_work_spine/input \
  --out receipts/first_wave/mission_transaction_work_spine

To validate the exported source bundle:

PYTHONPATH=src python3 -m microcosm_core.organs.mission_transaction_work_spine \
  validate-mission-transaction-bundle \
  --input examples/mission_transaction_work_spine/exported_mission_transaction_bundle \
  --out receipts/first_wave/mission_transaction_work_spine

For the focused regression tests and the paper-module corpus check:

PYTHONPATH=src python3 -m pytest tests/test_mission_transaction_work_spine.py -q
PYTHONPATH=src python3 scripts/build_doctrine_projection.py --check-paper-module-corpus

A pass means the fixture rows, the copied source bodies, the real snapshot replay, and the fourteen negative cases all hold together, and the result records carry no private body. A pass means the fixture rows, the copied source bodies, the real snapshot replay, and the fourteen negative cases all hold together, and the result records carry no private body.