implementation_status.csv

REQ_ID,STATUS,ISSUE,PR,MERGE_COMMIT,EVIDENCE
REQ-MIGRATION-001,IMPLEMENTED,23,24,7d732d1ffe3f73f202d63dc82baf8f3125a13ce9,"`dotnet build --configuration Release` (0 warnings, 0 errors) and the full `TradeCraftSimulation.Tests` suite (44/44 passed, 0 failed, 0 skipped) at revision `10af216915bd96f680ec6da4197f408175c96509`, matching Gate M0's ""build succeeds and all existing tests pass unchanged"""
REQ-MIGRATION-002,IMPLEMENTED,39,40,6063ed9151d86e1650f53a36441bcd9aa64ddeb2,"`TradeCraftSimulation.Tests.LegacyBaselineSnapshotTests.The_seed_7_thirty_turn_baseline_matches_the_frozen_expected_hash`, pinning the seed-7/30-turn normalized hash documented in `docs/spec/LEGACY_BASELINE.md` against a checked-in expected SHA-256, satisfying the strengthened `CODE_RUNTIME_QA_02` acceptance; 45/45 `TradeCraftSimulation.Tests` passed at the merge commit"
REQ-MIGRATION-003,IMPLEMENTED,27,29,1fb089368434abc2d875a553225f6f73d042da41,"`src/config/index.test.ts`, `src/domain/index.test.ts`, `src/simulation/index.test.ts`, `src/diagnostics/index.test.ts` (one per new module area) and `src/index.test.ts`'s `canonicalScaffolding` assertion; `npm ci`, `npm run typecheck`, `npm test`, `npm run build`, `dotnet build --configuration Release` and `dotnet test --configuration Release` all green in the same pull request"
REQ-MIGRATION-004,IMPLEMENTED,41,43,33683dd4224cac869d2eac982f756ae8fdb6ea7f,"`src/diagnostics/isolationBoundary.test.ts` — `finds zero cross-runtime references in the current M0 source trees` audits the real `src/` and `TradeCraftSimulation/` trees for textual cross-references; two negative-control tests (`rejects a canonical file that imports the legacy tree`, `rejects a legacy file that reads canonical module output`) prove the underlying scan actually rejects a fixture-only prohibited reference; a third negative-control test (`auditRepositoryIsolationBoundary rejects a similarly-named-but-distinct file that the guard-module exclusion must not swallow`) proves, through the real `auditRepositoryIsolationBoundary` traversal rather than the pure scan alone, that the guard's own file-exclusion is an exact path match and does not silently exempt unrelated similarly-named files (closing a false-negative operator QA and ACCEPTOR review both reproduced against an earlier revision of this pull request). Documented in `docs/spec/MIGRATION_BOUNDARY.md`."
REQ-VISUALIZATION-003,IMPLEMENTED,42,45,d27a94e63580a2d7d0da005a245ae36fec5560fd,"`src/diagnostics/m0Preview.test.ts` — asserts `docs/m0-preview.json`'s legacy baseline seed/turns/hash match `docs/spec/LEGACY_BASELINE.md` exactly, its canonical-scaffolding flag matches the real `toolchainStatus()` in `src/index.ts`, and `docs/index.html` fetches the static artifact without referencing any canonical or legacy runtime module path. Manual build/render smoke check (headless-Chromium screenshots at 1280×1000, 360×900, and a full-page 1100×1900 capture) against a local static server, described in `docs/spec/M0_PREVIEW.md`; 7 files / 16 tests passed and both runtime suites green at merge commit `d27a94e63580a2d7d0da005a245ae36fec5560fd`. Actual production GitHub Pages deployment was explicitly out of AUTHOR scope in #45 and has not been independently re-verified by this reconciliation, which is bounded to `gh pr list` and the merged pull request's own body per `AUTHOR_RUNBOOK.md` section 1."
REQ-CORE-001,IMPLEMENTED,46,48,58a0b49156131ec81fcb23d357f7e15b327bde4d,"`src/domain/id.test.ts` (13-kind prefix table, per-kind sequential allocation, duplicate-creation-key rejection, cross-run replay determinism, stable creation-key-order contract independent of array/Map build order, `CORE-T16` retirement/non-reuse including wrong-kind and double-retire rejection, and the corrected-head regressions verified at `c584d830ce46d68a398c089b06d72b1ced7b33c0` — failure-atomic batch allocation and runtime kind/creation-key validation) plus `src/domain/id.typecheck.test.ts` (`tsc --noEmit` regressions proving distinct ID kinds and bare strings are not mutually assignable). See `docs/adr/0003-canonical-identity-and-allocation.md` for the design."
REQ-CORE-002,IMPLEMENTED,57,58,002343805d14a4d3b43faf089aef9f7d52da9d4a,"`src/domain/numeric.test.ts` (rejects `NaN`/`+Infinity`/`-Infinity`/non-number input, accepts ordinary finite numbers including `0` and negative values) and `src/domain/ordering.test.ts` (`stableOrderBy`/`sortByPersistentId` produce an identical normalized result from differently-shuffled input — `CORE-T2`-shaped evidence — using `src/domain/id.ts` IDs as the concrete key type; a dedicated non-identity assertion proves the sort actually reorders rather than passing vacuously)."
REQ-CONFIG-001,IMPLEMENTED,64,67,493da16e53e58e78a830ad44f1da627f9196742c,"`src/config/configLayers.typecheck.test.ts` (`tsc --noEmit` regressions proving `RunOptions`, `SimulationConfig`, `ScenarioDefinition` and `DefinitionPack` are structurally distinct, non-interchangeable types) and `src/config/validation.test.ts` (`assertNoBehavioralOverrides` accepts a minimal well-formed scenario and the legitimate array-shaped `markets`/`clans` seed fields; rejects a `SimulationConfig`-owned behavioral key including the `markets`/`clans` name-collision case where the smuggled value is an object rather than an array; rejects an arbitrary unknown key; rejects a non-object candidate)."
REQ-CONFIG-002,IMPLEMENTED,69,70,005d0a553dbc685b8bf554ff0ae9d802a7ac04fd,"`src/config/rng.test.ts` (`deriveKeyedRandom` reproduces the same value across repeated calls with the same key; yields identical per-key results regardless of evaluation order over a fixed key set; changes value when seed, tick, phase or key individually differ; does not collide across a naive delimiter-ambiguous key composition; returns a value in `[0, 1)`; rejects a non-finite seed/tick and an empty phase/key)."
REQ-CORE-003,IMPLEMENTED,72,73,3b6f2ebc87c204de75e0f2064df3c33f9e9efb48,"`src/domain/worldRegistries.test.ts` (`buildWorldRegistries` creates exactly the scenario-defined entity counts for Region/State/Currency/Clan/PopulationCohort/ProductionUnit; leaves `transportLinks`/`markets` legitimately empty when the scenario omits or empties those seed lists; every entry is keyed by its own allocated ID with the correct id-kind prefix and no duplicate ID within or across registries; repeated genesis with the same scenario and a fresh allocator is field-equivalent) and `src/domain/definitionRegistry.test.ts` (`buildDefinitionRegistry` carries a `DefinitionPack`'s `goods`/`recipes`/`eventDefinitions`/`metricDefinitions` through unchanged, including the empty case)."
REQ-CONFIG-003,IMPLEMENTED,299,300,91507ac339b1fed65a8d0970941e8fc74eacc87c,"Foundation (PRs #79, #156, #163, #173) plus repair attempts: PR #288 (Issue #200) added MarketId validation and RecipeDefinition bounds checking; SLOPSTER QA post-merge finding identified missing extraction resource/amount coupling validation. PR #300 (Issue #299, merged 2026-09-08T10:33:11Z) enforces section 16A coupling constraint: validateDefinitionPack rejects extraction recipes with extractionResourceId but no extractedResourcePerBatch, extractedResourcePerBatch without extractionResourceId, or non-positive extractedResourcePerBatch. Tests: src/config/validation.test.ts lines 774-807 (three focused rejection cases + one acceptance path). TypeScript: 442 tests passed, typecheck clean, build succeeded. C#/.NET: 45 tests passed, build clean (REQ-MIGRATION-003 maintained)."
REQ-CONFIG-004,IMPLEMENTED,455,473,9a7fdd855a69a4a44b31c505b1f0ccfa23142a11,"Composite multi-PR completion: PR #208 (Issue #201, merge 83ff432) delivered aggregate-only reconciliation; PR #315 (Issue #306, merge 68aca0d) added owner-bound identity validation for money, goods, capital, population and resources with negative tests for owner/location swaps; PR #324 (Issue #317, merge 35b1717) completed final FX-pool reserve reconciliation with MonetaryAuthority wallet repair, extending genesis ActorRef with MONETARY_AUTHORITY, emitting owner-bound MONEY_ENDOWMENT records for wallet balances, reconciling them separately from FX_POOL_OPENING, projecting FX-pool base/quote reserves at pool+currency granularity, and including equal-and-opposite cross-pool control. All canonical stock categories (money, goods, population, capital, resources) reconcile within configured canonical tolerance 1e-9. Tests: 475+ TypeScript tests passed; typecheck clean; build succeeded; legacy .NET 45 tests passed (REQ-MIGRATION-003 maintained). Acceptance: opening stock reconciliation passes within canonical tolerances for every tracked stock category. PR #329 (Issue #325, merge 10146155be38ea3fa103dd162a6b8891334e65c9) recorded that composite as IMPLEMENTED and is this row's prior merge evidence. PR #459 (Issue #448) found and repaired a genuine gap this evidence overstated: buildInitialWorld() step 8 recorded every cohort MONEY_ENDOWMENT, GOOD_ENDOWMENT and POPULATION_ENDOWMENT with owner: { type: ""CLAN"", clanId } instead of the cohort itself, and genesisReconciliation.ts's cohort actual-side projection used the same Clan key -- so a cohort stock misattributed to (or moved from) its Clan was invisible to owner-bound reconciliation as long as the aggregate total was unchanged, and population reconciliation was not owner-bound at all (keyed only by sourceSeedKey). PR #459 adds COHORT to the genesis-ledger ActorRef union (already canonical per Handoff/01 section 7), attributes cohort wallet/household-inventory/population genesis records to the cohort rather than the Clan, makes population reconciliation owner-bound the same way money/goods/capital already are, and adds three owner-swap negative controls (money, goods, population) proving a cohort-to-Clan relabeling now fails reconciliation. TypeScript: 581 tests passed (40 files, 7 new), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). PR #461 (Issue #450) restored capital-good identity: CAPITAL_ENDOWMENT is emitted and reconciled at (ProductionUnit owner, capital goodId), with the per-good quantity derived from the documented Handoff/03 section 20 conversion (recipe investmentGoodsPerCapitalUnit) through one shared resolver used by both the emitting and the reconciling side, replacing a fabricated ""capital"" goodId that no definition pack declares; capital whose recipe declares no investment good records no goodId (canonical goodId?: GoodId) and still reconciles owner-bound. Proving test: genesisReconciliation.test.ts ""fails when capital is relocated between capital goods of one ProductionUnit while the unit's total is unchanged"" - it is the only test in the suite that fails when the capital key is reduced to owner alone, so it is sensitive to good identity and to nothing else. At revision c0f0259 the TypeScript suite passed 577/577, typecheck and build passed, and legacy .NET passed 45/45. Three sibling REQ-CONFIG-004 identity defects remain open and unfixed by either PR #459 or PR #461: Issue #449 (GOOD_ENDOWMENT region identity discarded before comparison), #451 (RESOURCE_ENDOWMENT reconciled by descriptive sourceSeedKey string rather than typed regionId/goodId) and #452 (POPULATION_ENDOWMENT region identity), alongside #455 (ProductionUnit GOOD_ENDOWMENT inventory-bucket identity). REQ-CONFIG-004 therefore stays PARTIAL rather than IMPLEMENTED: the requirement's own acceptance (""Opening stock reconciliation passes within canonical tolerances for every tracked stock category"") is not yet truthfully provable at full typed-identity granularity. PR #467 (Issue #449) closes the GOOD_ENDOWMENT location-identity half: genesis reconciliation now keys goods by owner + region + good on both sides instead of owner + good, so a same-owner/same-good relocation between two regions no longer passes on an unchanged aggregate. The actual-stock projections derive location from the owning entity's own region (CohortSeed.regionKey / ProductionUnitSeed.regionKey resolved through the region registry), not from an aggregate container. A State's public inventory is held by the State itself rather than by any one region it controls and is therefore not region-bound: GOOD_ENDOWMENT.regionId is now optional (matching the canonical ""regionId?: RegionId"" declaration in Handoff/03 section 20), world genesis no longer fabricates a placeholder region for it (the removed lookup compared region keys against a state key and always resolved to undefined), and both sides carry an explicit unlocated key segment. Two proving tests were added to genesisReconciliation.test.ts: ""fails when a cohort's household inventory is relocated to another region while the owner+good total is unchanged"" and the ProductionUnit equivalent; both were confirmed sensitive by neutralizing the region key segment, under which exactly those two tests fail and the other 25 in the file pass. A third test asserts cohort and ProductionUnit good endowments are recorded at the owning entity's own region. At revision 255d741 the TypeScript suite passed 587/587 (40 files), typecheck and build passed, and legacy .NET passed 45/45 (REQ-MIGRATION-003 maintained). REQ-CONFIG-004 stays PARTIAL: sibling typed-identity defects #451 (RESOURCE_ENDOWMENT reconciled by descriptive sourceSeedKey rather than typed regionId/goodId), #452 (POPULATION_ENDOWMENT region identity) and #455 (ProductionUnit GOOD_ENDOWMENT inventory-bucket identity; the three buckets still aggregate together after this PR) remain open, so the requirement is not yet truthfully provable at full typed-identity granularity. PR #469 (Issue #451) closes the RESOURCE_ENDOWMENT typed-identity half: resource deposits are now reconciled by (regionId, goodId) on both sides instead of by the descriptive sourceSeedKey string. Before this change the expected side keyed on record.sourceSeedKey while the actual side independently rebuilt the same string from region.seed.key and deposit.resourceId, so a ledger record naming the wrong regionId or the wrong goodId reconciled cleanly as long as its source key and amount were untouched; the comparison proved agreement of two descriptive strings, not canonical stock identity. The actual-side projection now reads the region as the region registry's own RegionId (the worldState.regions map key) rather than reconstructing it from a seed key, and sourceSeedKey remains on the record as provenance only, which is all Handoff/03 section 20 permits it to be. The emission site in worldState.ts replaced a 'deposit.resourceId as any' cast commented 'Simplified; would need GoodId lookup' with a typed conversion: goods carry no allocated id anywhere in genesis accounting (GOOD_ENDOWMENT keys on inventory key strings the same way) so the deposit's resource key is the good identity reconciliation compares, and that field is now load-bearing. Two proving tests were added to genesisReconciliation.test.ts: 'fails when a resource deposit is relabeled into another region while its source key and amount are unchanged' and 'fails when a resource deposit is relabeled as another good while its source key and amount are unchanged'. Each asserts that the relabelled record's sourceSeedKey and amount are identical to the original and that total recorded resource quantity is unchanged before asserting failure, so neither can pass on a quantity change. Both were confirmed sensitive by restoring genesisReconciliation.ts to its master content with the tests in place: exactly those two fail (2 failed | 27 passed) and restoring the repair returns 29/29. At revision e338f3367d813f2a084ce9e542a901f5eb3f1287 the TypeScript suite passed 589/589 (40 files, 2 new), typecheck and build passed, and legacy .NET passed 45/45 (REQ-MIGRATION-003 maintained). REQ-CONFIG-004 stays PARTIAL: sibling typed-identity defects #452 (POPULATION_ENDOWMENT region identity) and #455 (ProductionUnit GOOD_ENDOWMENT INPUT/OUTPUT/INVESTMENT bucket identity, the subject of spec changelog entry HANDOFF-REPAIR-017; the three buckets still aggregate together after this PR) remain open, so the requirement is not yet truthfully provable at full typed-identity granularity. PR #471 (Issue #452) closes the POPULATION_ENDOWMENT location-identity half: cohort population is now reconciled by (cohort owner, regionId) on both sides instead of by owner alone. A POPULATION_ENDOWMENT record carries its cohort's Region typed and required, but the comparison never read it, so a record naming the wrong Region reconciled cleanly while owner, sourceSeedKey, amount and total population were unchanged. The expected side now keys on the record's own regionId; the actual side resolves the cohort's Region through the region registry from CohortSeed.regionKey -- the same canonical cohort/region relation and the same registry lookup the goods projection already uses -- rather than from any seed-key text, so sourceSeedKey stays provenance only as Handoff/03 section 20 requires. This extends the single population key introduced by PR #459 rather than adding a parallel owner/region convention, satisfying Issue #452 criterion 4. One proving test was added to genesisReconciliation.test.ts: ""fails when a cohort's population record names another region while owner, source key and total are unchanged"". It first asserts the unmodified genesis reconciles, then asserts the relabelled record's owner, sourceSeedKey and amount are identical to the original and that total recorded population is unchanged, so it cannot pass on a quantity or owner change. It was confirmed sensitive by stashing genesisReconciliation.ts back to its master content with the test in place: exactly that test fails (1 failed | 29 passed) and restoring the repair returns 30/30. At revision b2a15c4e34d644514064dae7d6530d52471df48f (the code commit; the ledger row itself is the only later change on the branch) the TypeScript suite passed 590/590 (40 files, 1 new), typecheck and build passed, and legacy .NET passed 45/45 (REQ-MIGRATION-003 maintained). REQ-CONFIG-004 stays PARTIAL: sibling typed-identity defect #455 (ProductionUnit GOOD_ENDOWMENT INPUT/OUTPUT/INVESTMENT bucket identity, the subject of spec changelog entry HANDOFF-REPAIR-017; the three buckets still aggregate together after this PR) remains open, so the requirement is not yet truthfully provable at full typed-identity granularity. PR #473 (Issue #455) closes the last named typed-identity defect: ProductionUnit GOOD_ENDOWMENT inventory-bucket identity, the subject of spec changelog entry HANDOFF-REPAIR-017. Before this change worldState.ts emitted inputInventory, outputInventory and investmentInventory as three GOOD_ENDOWMENT records distinguished only by their sourceSeedKey text, and genesisReconciliation.ts summed all three into one owner+region+good key on both sides, so a same-quantity INPUT<->OUTPUT<->INVESTMENT relocation reconciled cleanly -- section 20 requires the comparison to be ProductionUnit + region + inventoryBucket + goodId and permits sourceSeedKey to be provenance only. The baseline scenario makes the hole reachable rather than theoretical: the iron mine holds good:iron as both INPUT (80) and OUTPUT (300), and the tools-craft unit holds good:tools as both OUTPUT (150) and INVESTMENT (50). genesisLedger.ts now declares an InventoryBucket type and splits GOOD_ENDOWMENT into a ProductionUnit-owned member requiring inventoryBucket and a member for every other owner that may not carry one; a Cohort holds one householdInventory and a State one publicInventory, neither of which is an INPUT/OUTPUT/INVESTMENT container, so both the requirement and the prohibition are compile-time rather than a runtime check. Reconciliation builds one goodStockKey(owner, region, bucket, good) shared by the expected projection and all three actual projections, and ReconciliationResult.details.key therefore names the diverging bucket rather than only the unit and the good. Three tests were added to genesisReconciliation.test.ts: a cross-bucket split that asserts the owner+region+good aggregate is unchanged (toBeCloseTo at 12 digits) before asserting failure and asserts the reported key contains the source bucket; a bucket relabel of the iron mine's INPUT iron, whose unit total for that good is unchanged by construction because its OUTPUT iron already exists; and a positive test that each opening inventory is recorded under its own bucket, asserting all three buckets appear so it cannot pass vacuously. Two more were added to genesisLedger.test.ts for the typed record shape. The negative controls were confirmed sensitive by collapsing the bucket key segment to the unbucketed sentinel, reproducing master's aggregate behaviour on both sides: exactly the two new controls fail (2 failed | 31 passed) and restoring the repair returns 33/33. At revision bd0a806c05b8cc9e5b1d4ba4beb2f8d25bc46c7f the TypeScript suite passed 594/594 (40 files, 5 new), typecheck and build passed, and legacy .NET passed 45/45 (REQ-MIGRATION-003 maintained). REQ-CONFIG-004 moves from PARTIAL to IMPLEMENTED: every typed-identity defect named by the PARTIAL rationale of PRs #459, #461, #467, #469 and #471 is now closed -- cohort owner identity (#448/#459), capital-good identity (#450/#461), GOOD_ENDOWMENT region identity (#449/#467), RESOURCE_ENDOWMENT typed region/good identity (#451/#469), POPULATION_ENDOWMENT region identity (#452/#471) and ProductionUnit inventory-bucket identity (#455, this PR) -- and no further REQ-CONFIG-004 Issue is open, so the requirement's acceptance (opening stock reconciliation passes within canonical tolerances for every tracked stock category) is now provable at full typed-identity granularity for money, goods, population, capital and resources."
REQ-CONFIG-005,IMPLEMENTED,514,516,c56674f761e41ff024ed8001cd66fc32845d48f6,"Two merged slices. #76 (Issue #74) added top-level shape validation in `src/config/shapeValidation.ts`, proved by `src/config/shapeValidation.test.ts` (`rejects geography given as a plain object instead of an array`, `rejects a present variation given as an array or non-object`, `rejects a non-object candidate` for both `RunOptions` and `ScenarioDefinition`). #88 added `validateScenarioContent` in `src/config/validation.ts`, proved by `src/config/validation.test.ts`: invalid cross-references (`rejects a region with invalid controllerStateKey`, `rejects a region with invalid settlementCurrencyKey`, `rejects a transport link with invalid region references`, `rejects a cohort with invalid regionKey`, `rejects a production unit with invalid owner reference`), out-of-range values (`rejects a transport link with condition out of [0,1]`, `rejects a cohort with out-of-range healthIndex`, `rejects a cohort with negative population`, `rejects a market with zero or negative price`) and `rejects non-finite values in numeric fields`. Each rejection asserts on the thrown diagnostic, so ""fail fast with useful diagnostics; do not silently coerce"" is proved rather than assumed. Recorded here after reading the merged code, superseding #105, which promoted the status while leaving evidence that described only the #76 slice. PR #502 (Issue #465) closes a hole this evidence did not cover: `validateDefinitionPack()` never inspected `RecipeDefinition.investmentGoodsPerCapitalUnit`, so the fail-fast invariant this row claims (""Invalid references, non-finite values and out-of-range configuration fail fast with useful diagnostics; do not silently coerce"") did not hold for that field. `resolveCapitalGoodsPerCapitalUnit()` (`src/domain/definitionRegistry.ts`) was the first and only consumer on the genesis path and it drops any entry that is not finite and > 0, so a `NaN`, `Infinity`, zero or negative coefficient yielded an empty result - indistinguishable from a recipe that genuinely declares no investment good. That is silent coercion, and it was invisible to every existing conservation test because `buildInitialWorld()` and `reconcileGenesisStocks()` resolve through the same filter: both sides shared one reinterpretation and therefore agreed. The filter had no key-side check either, so a coefficient naming a good the pack does not declare was dropped by the same path rather than rejected. `validateDefinitionPack()` now rejects, before any world construction, a coefficient that is non-finite or <= 0 and a coefficient keyed by an undeclared good, with a diagnostic naming the recipe and the good; an empty map stays valid because it is a real ""no investment good"" declaration that the baseline pack relies on (`src/config/fixtures/baselineDefinitionPack.ts:121`). The resolver's filter is kept as defence-in-depth rather than promoted to an assertion - validation is authoritative on the genesis path, but the resolver is also reachable from a registry assembled without it, and loosening one of the two callers only would let the emitting and reconciling sides disagree. Proving tests: six in `src/config/validation.test.ts` (`NaN`, `+Infinity`, `-Infinity`, zero, negative, unknown good key) and six in the new `src/simulation/genesisInvestmentCoefficients.test.ts`, which runs the finding's own reproduction end to end - the baseline pack with `recipe:tools-craft`'s coefficient made invalid, then `buildInitialWorld()` on the otherwise-valid baseline scenario - plus four acceptance tests proving the unmodified baseline pack, a strictly positive coefficient and an empty map all still pass. The negative control was run: restoring `src/config/validation.ts` to its `master` content with the tests in place fails exactly the twelve rejection tests and passes the other 54 (12 failed | 54 passed of 66); restoring the repair returns 66/66. At revision e00272f the TypeScript suite passed 671/671 (46 files), typecheck and build passed, and legacy .NET passed 45/45 (REQ-MIGRATION-003 maintained). A two-part researcher feedback entry is filed in the same pull request: the specification states no per-coefficient bound for this field (the strictly-positive rule is an inference from the divide at `06 - Handoff/05 - PRODUCTION_CAPITAL_LABOR_CONTRACTS.md:463`, the same argument HANDOFF-REPAIR-015 used for `inputsPerBatch` but never carried across), and its only prose annotation - ""at least one good for capital-forming recipes"" - is unmeasurable because ""capital-forming recipe"" is defined nowhere and is in tension with the baseline's own empty map. PR #510 (Issue #508) closes the same hole in the sibling good-keyed map: `validateDefinitionPack()` checked every `RecipeDefinition.inputsPerBatch` entry for a finite coefficient > 0 but never tested its key against `declaredGoodKeys`, although the function builds that set once per pack and the `investmentGoodsPerCapitalUnit` check above it consults it, in the same loop over the same set. An undeclared input Good with a well-formed coefficient therefore passed world-genesis step 1 and reached canonical world construction, against Handoff/03 section 21 (""unknown Good/Recipe/Event/Metric IDs"" fail fast) and section 19 step 1 (validation precedes construction). The key is now checked before the coefficient bound, with a diagnostic naming the recipe and the unknown Good; an empty map and a declared good with a strictly positive coefficient stay valid. Proving tests: three in `src/config/validation.test.ts` under `inputsPerBatch good references (REQ-CONFIG-005)` and four in the new `src/simulation/genesisInputGoodReferences.test.ts`, which runs the finding's own reproduction end to end - the baseline pack with `recipe:tools-craft` given an undeclared input Good, then `buildInitialWorld()` on the otherwise-valid baseline scenario - alongside acceptance cases for the unmodified pack, the baseline inputs and an empty map. The negative control was run: with the membership guard removed and the tests in place, exactly the three undeclared-Good rejections fail and the other 70 tests in those files pass (3 failed | 70 passed of 73); restoring the guard returns 73/73. At revision 737ff36 the TypeScript suite passed 679/679 (47 files), typecheck and build passed, and legacy .NET passed 45/45 (REQ-MIGRATION-003 maintained). This row's STATUS is deliberately left at IMPLEMENTED rather than downgraded, because the change strictly increases coverage and asserts nothing new - but the coverage it claims is not total, and the remaining gap is named here rather than left for a later run to rediscover: `RecipeDefinition.outputGoodId` is read nowhere in `validateDefinitionPack()` and appears outside tests only in the type declaration and the baseline fixtures, so the step-1 validator still accepts a recipe producing a Good the pack does not declare. Whether any downstream layer rejects it was not measured; #508's Non-goals excluded that field. Filed as Issue #509 (status:needs-triage). PR #512 (Issue #509) closes the last of the three Good references a recipe carries. `validateDefinitionPack()` built `declaredGoodKeys` once per pack and consulted it for both good-keyed maps - `investmentGoodsPerCapitalUnit` (#502) and `inputsPerBatch` (#510) - but never for the scalar `RecipeDefinition.outputGoodId`, which the preceding text of this cell named as the remaining gap and left unmeasured. It is measured now: outside tests, `outputGoodId` appears only in the type declaration (`src/config/definitionPack.ts:45`) and the three baseline fixture recipes, and no canonical code reads it, because production is M4 and is not implemented. So no downstream layer rejected an undeclared output Good either - unlike an undeclared investment good, which `resolveCapitalGoodsPerCapitalUnit()` at least drops, this reference reached the constructed world untouched. That makes it a latent fail-fast gap rather than an observable production defect, and it still violates Handoff/03 section 21 (unknown Good/Recipe/Event/Metric IDs fail fast), section 24 invariant 3 (all IDs reference-valid) and section 19 step 1 (validation precedes construction). The check now runs before the `outputPerBatch` bound and throws a diagnostic naming the recipe and the unknown Good, matching the two sibling checks. Proving tests: four in `src/config/validation.test.ts` under `outputGoodId good reference (REQ-CONFIG-005)` - an undeclared output good, an undeclared output good with every other field well-formed, the diagnostic naming the offending recipe among several, and a declared output good accepted - and three in the new `src/simulation/genesisOutputGoodReference.test.ts`, which runs the reproduction end to end through `buildInitialWorld()` on the otherwise-valid baseline scenario alongside acceptance cases for the unmodified baseline pack and for the recipe repointed at a different declared Good. The negative control was run: with the membership guard removed and the tests in place, exactly the four rejection regressions fail and the other 68 tests in those files pass (4 failed | 68 passed of 72); restoring the guard returns 72/72. At revision 446ca35 the TypeScript suite passed 686/686 (48 files), typecheck and build passed, and legacy .NET passed 45/45 (REQ-MIGRATION-003 maintained). STATUS stays IMPLEMENTED: the change strictly increases coverage and asserts nothing new. `extractionResourceId` remains unchecked and is deliberately excluded - it names a resource rather than a Good and is a separate question, recorded in the #509 text. No researcher feedback was filed for this slice: the governing section 21 text is unambiguous for this field. PR #516 (Issue #514) closes the field this cell named as deliberately excluded: `RecipeDefinition.extractionResourceId`. Section 21 of Handoff/03 fails configuration validation on ""recipe extraction referring to a resource absent from all eligible regions when the baseline expects that recipe to operate"", and nothing enforced it. `validateDefinitionPack()` checked only that `extractionResourceId` and `extractedResourcePerBatch` appear together with a finite positive amount (`src/config/validation.ts`), and `validateWorldGenesis()` covered scenario/version, key uniqueness and currency references only, never relating a recipe to `RegionSeed.deposits`. Unlike the three earlier slices this check could not be added where they live: the recipe is a DefinitionPack fact and the deposits are a ScenarioDefinition fact, and `validateDefinitionPack(definitionPack)` never sees the scenario while `validateScenarioContent(scenario)` never sees the pack. `validateWorldGenesis(scenario, definitionPack, config)` holds both and already runs as step 1 of `buildInitialWorld()`, satisfying section 19 step 1; the new `validateExtractionResourcesPresent()` is called from there (`src/simulation/worldState.ts`). Nothing downstream would have caught it either: extraction is M4 work, so outside tests `extractionResourceId` is read only by the coupling check itself, and an absent resource reached the constructed world untouched. The rule implemented is the strictly weaker of the two available readings - reject only when the resource is absent from EVERY Region in the scenario while some ProductionUnit seed on that recipe starts `ACTIVE` - because ""eligible regions"" is defined nowhere in the governing document. The eligible set is a subset of all Regions under either reading, so absence from every Region entails absence from all eligible ones and this cannot over-tighten; the narrow per-Region reading is not merely unproven but would reject the shipped baseline, whose `recipe:iron-mine` units in `region:b6-mineral` and `region:d3-mountain` deposit `resource:copper-ore` rather than the `resource:iron-ore` they extract. That ambiguity was reported to the researcher in the same pull request rather than decided in code. Proving tests: five in the new `src/simulation/genesisExtractionResource.test.ts`, which runs the Issue's own reproduction end to end - the baseline pack with `recipe:iron-mine` repointed at `resource:not-defined`, then `buildInitialWorld()` on the otherwise-valid baseline scenario - alongside the unmodified-baseline positive control, a resource deposited only in Regions other than the mines' own (acceptance criterion 3, proving the rule was not tightened per Region), a direct assertion that the shipped baseline itself relies on that looseness, and the `ACTIVE`-predicate boundary where an all-MOTHBALLED scenario does not expect the recipe to operate and is accepted. The negative control was run: with the call to `validateExtractionResourcesPresent()` disabled and the tests in place, exactly the absent-resource regression fails and the other four pass (1 failed | 4 passed of 5); restoring the call returns 5/5. At revision 73e4957 the TypeScript suite passed 691/691 (49 files), typecheck and build passed, and legacy .NET passed 45/45 (REQ-MIGRATION-003 maintained). STATUS stays IMPLEMENTED: the change strictly increases coverage and asserts nothing new."
REQ-CORE-004,IMPLEMENTED,185,187,be1eb42f0a38bab639318ff775c9d85162b363c5,"Canonical tick orchestrator and 16-phase framework (M2). tickOrchestrator.ts defines TickContext (tick-scoped ephemeral state), PendingTransitions (regime/policy changes queued for N+1+), and PhaseHandler type for pluggable phase logic. executeTick() runs phases 0-15 sequentially; computeTickHash() provides deterministic replay verification. 25 comprehensive tests (tickOrchestrator.test.ts): phase constants (2), TickContext initialization (3), phase execution (3), full tick trace (3), deterministic hash (4), no-op handler (3), 100+ tick scenario (3), PendingTransitions barrier (2). All acceptance criteria met: WorldState immutable, TickContext carries phase semantics, orchestrator sequential 0-15, phase-trace test proves no phase 16, 100+ ticks preserve stocks, deterministic hash stable, no undocumented mutation paths. TypeScript: 219 tests passed, typecheck clean, build succeeded. C# (.NET 9): 45 tests passed, build clean (REQ-MIGRATION-003 maintained). REQ-CORE-004 ready for M2 gate. Evidence: docs/spec/implementation_status.csv row 16 (PR #187)."
REQ-CORE-006,IMPLEMENTED,332,333,ec1dd89,"Composite multi-PR completion across four merged pull requests: PR #226 (Issue #192) foundation ledger/reconciliation framework; PR #239 (Issue #235) TickLedger integration with phase-N → phase-N+1 bookkeeping and compensating flows; PR #326 (Issue #310) phase-boundary fail-fast validation with keyed diagnostics (category/key/residual). PR #333 (Issue #332, merged 2026-09-09T04:09:18Z as `ec1dd896ea067fd886870d4f246e9644cc6cfb89`) completed final acceptance gaps: fixed keyed reconciliation to exclude owner-inclusive account matching (reconcile by `currencyId` for MONEY and `goodId` for GOOD only, canceling equal-and-opposite transfers between different owners); added PHYSICAL_LOSS runtime validation rejecting non-finite and negative amounts at `addLedgerRecord()`; propagated keyed diagnostics through `PhaseBoundaryValidationError`. All CORE-006 acceptance criteria verified at merge: different-owner currency transfers cancel at conserved-asset level; separate-currency mismatches surface keyed diagnostics; GOOD reconciliation by `goodId` independent of owner; PHYSICAL_LOSS standalone entries validated; invalid NaN/Infinity/negative loss amounts rejected with diagnostic; keyed diagnostics propagate through phase-boundary validation. TypeScript: 540+ tests passed, typecheck clean, build succeeded. C#/.NET: 45 tests passed, build clean (REQ-MIGRATION-003 maintained). REQ-CORE-006 complete and ready for M2 gate."
REQ-ACCEPTANCE-002,IMPLEMENTED,228,229,b642f4c517efa898a8b3c13b7be3e7e25abee805,"Deterministic replay hash for 100+ ticks at M2. New integration test suite (src/simulation/acceptance-002-replay-determinism.test.ts) proves: (1) Baseline scenario builds without error and produces frozen WorldState; (2) 100+ consecutive no-op ticks execute without error preserving stocks exactly (zero transactions); (3) Repeated same-seed 100-tick runs produce identical normalized SHA-256 hashes across multiple independent runs; (4) Different seeds produce different hashes; (5) Phase order remains consistent (phases 0-15) across all ticks; (6) Genesis reconciliation passes before tick execution; (7) Each hash is valid hex and tick-dependent; (8) At least 120 ticks (exceeding 100-tick gate) maintain determinism. Test coverage: 22 comprehensive tests in acceptance-002-replay-determinism.test.ts covering construction, execution, determinism, different seeds, configuration replayability, zero-flow reconciliation, and phase trace consistency. Acceptance criteria fully satisfied: 100+ no-op ticks stable, same-seed determinism proved, different-seed differentiation proved, replay hash deterministic and replayable. TypeScript verification: 250 tests passed (24 files), typecheck clean, build succeeded. C#/.NET: 45 tests passed, build clean (REQ-MIGRATION-003 maintained)."
REQ-VISUALIZATION-004,IMPLEMENTED,160,220,f199c8677e99256c4b9ca46d68772b80ef7aa1b3,"M1 Milestone Preview (REQ-VISUALIZATION-004): deterministic JSON snapshot of canonical world-gen overview without exposing mutable domain objects. src/diagnostics/m1Preview.ts generates typed M1Preview interface exposing scenario ID/seed/configVersion, world topology counts (stateCount, regionCount, currencyCount, etc.), and arrays of State/Currency/Region/Clan details. src/diagnostics/m1Preview.test.ts (12 tests) generates docs/m1-preview.json from baseline-multistate-v1 scenario and seed 42; asserts M1Preview schema completeness, non-zero entity counts, deterministic generation invariance, and that docs/index.html references m1-preview.json without runtime imports. Smoke test: generated artifact is deterministically serializable, contains 4 states (State Alpha/Beta/Gamma/Delta), 24 regions, 4 currencies, 8 clans, 216 cohorts, 172 production units. All acceptance criteria met: M1 preview JSON generated deterministically from baseline scenario; GitHub Pages displays world-gen topology via static artifact (no mutable WorldState exposure); one-way read-only diagnostic output; TypeScript 231/231 tests passed, typecheck clean, build succeeded; C# 45/45 tests passed, build clean (REQ-MIGRATION-003 maintained)."
REQ-VISUALIZATION-005,IMPLEMENTED,411,479,becbcf0076c3205f13834176285b26dc49ae5732,"M2 Milestone Preview (REQ-VISUALIZATION-005): deterministic JSON snapshot of canonical M2 tick orchestration and zero-flow reconciliation without exposing mutable domain objects. src/diagnostics/m2Preview.ts generates typed M2Preview interface exposing scenario ID/seed/configVersion, world topology counts, phase trace (0-15 proof with no phase 16), tick counter (firstTick/lastTick/ticksExecuted = 1/101/101), and reconciliation health (passedTicks=101/failedTicks=0/tolerance=1e-9). src/diagnostics/m2Preview.test.ts (13 tests) generates docs/m2-preview.json from baseline-multistate-v1 scenario and seed 42 executing 101 no-op ticks; asserts M2Preview schema completeness, phase trace exactly 0-15 (no phase 16), tick counter preservation, reconciliation passes (all 101 ticks pass with zero unmatched deltas within tolerance 1e-9), deterministic generation invariance, and that docs/index.html references m2-preview.json without runtime imports. GitHub Pages displays tick/phase/reconciliation health via static artifact (no mutable WorldState exposure); one-way read-only diagnostic output. PR #244 (merged 5777e08957350dc610790f7e8cd59a0e5a70476d) delivered the M2Preview generator and JSON artifact. PR #368 (Issue #359, merged a89a8becd7aba073918a317a24b0341e482a6300) added a Pages render smoke test, but Issue #402 (SLOPSTER/researcher finding) showed those tests only fetched and inspected the JSON artifacts directly and never executed docs/index.html or observed a rendered DOM, so a broken DOM-population callback would leave every assertion green. PR #407 (Issue #402, merged 39c2c168388f44a6dff5cccbeefdd52763f92362) rewrote src/diagnostics/m1m2-pages-render.test.ts to load the real docs/index.html into jsdom with runScripts:'dangerously', bind window.fetch to the existing local static server, and assert on the actual rendered #m1-preview-body/#m2-preview-body DOM text after the preview fetches resolve; added desktop (1280px) and narrow (360px) viewport smoke cases and a DOM-population negative control per milestone. Issue #411 (QA/researcher finding) showed that PR #407's viewport smoke cases only checked getComputedStyle(...).display !== 'none' and textContent in jsdom, which has no box-model layout: a visibility:hidden or clipping (overflow:hidden + max-height:0) CSS rule on the populated preview body would leave every assertion green even though the content is not actually visible/readable. PR #421 (this PR, Issue #411) replaces those two viewport tests with real Chromium navigation via Playwright and asserts locator.isVisible(), which reflects an actual non-empty bounding box and non-hidden computed style; adds a Playwright devDependency and a pretest script (playwright install chromium) so npm test self-installs the browser; adds two negative-control tests proving a visibility:hidden regression on #m1-preview-body and a zero-height clipping regression on #m2-preview-body are each caught while DOM population/JSON fetch still succeed; preserves PR #407's DOM-population negative controls unchanged. ACCEPTOR review on PR #421's first head (independently confirming a SLOPSTER finding) showed Playwright's isVisible() does not check opacity, so an opacity:0 regression on a populated preview body would pass every positive assertion added by this PR. PR #421 (same branch, second head) added an isReadable() helper combining isVisible() with an explicit computed-opacity!=='0' check, used it for the two positive viewport tests' body assertions, and added a third negative-control test proving an opacity:0 regression on #m1-preview-body is caught while DOM population/JSON fetch still succeed. Verification: TypeScript 563/563 tests passed (40 files; 560 pre-existing + 3 net new: 2 viewport tests rewritten in place, 3 negative-control tests added), typecheck clean, build succeeded; C#/.NET 45/45 tests passed, build clean (REQ-MIGRATION-003 maintained). Issue #423 (researcher/QA finding on PR #421's merged head) showed the remaining false-positive path in that isReadable() helper: CSS opacity applies to an element and all of its contents but is not inherited, so a transparent ancestor composites the populated body away while the body's own computed opacity stays '1' and its bounding box stays non-empty. Injecting #m1-preview { opacity: 0; } therefore left isReadable(#m1-preview-body) returning true on a fully invisible preview. PR #479 (Issue #423) replaces the single-node opacity read with effectiveOpacity(locator), which multiplies each computed opacity along the ancestor chain from the target element to the document root inside the browser via locator.evaluate; isReadable() now gates on effectiveOpacity(...) > 0. It adds one negative-control test that injects #m1-preview { opacity: 0; } after navigation - leaving the JSON artifact, fetch URL and render callback untouched - and asserts that DOM population still succeeded, that isVisible() is still true and the body's own computed opacity is still exactly '1' (so the previous helper would have returned true), that isReadable() now returns false, and that the untouched M2 panel stays readable. The direct-opacity, visibility:hidden, clipping and DOM-population negative controls from PR #407 and PR #421 are preserved unchanged and still pass, and the normal 1280px/360px viewport cases still prove the populated bodies readable, so no actual normal-view failure was exposed and the row stays IMPLEMENTED per the researcher's 2026-09-11 triage on #423. Mutation-proved: with isReadable() reverted to its previous single-node form the new control fails with 'expected true to be false' (19 passed / 1 failed); with the fix all 20 pass. Gate is > 0, i.e. full transparency only - no perceptibility threshold was invented, and non-opacity mechanisms (filter, occlusion, clip-path, contrast) remain out of scope per #423's non-goals. Contributing pull requests for REQ-VISUALIZATION-005: #244, #368, #407, #421 and #479. Verification on PR #479's head: TypeScript 609/609 tests passed (41 files; 1 net new test), typecheck clean, build succeeded; C#/.NET 45/45 tests passed, build clean, 0 warnings (REQ-MIGRATION-003 maintained)."
REQ-MARKET-001,IMPLEMENTED,246,248,6c4dafba8a3cc65055ffc540f9bf69b8ac0e9a7a,"Ephemeral MarketIntent contract and budget commitment ledger for M3 local market procurement (sections 5-6 of MARKETS_TRADE_FX_CONTRACTS.md). src/simulation/marketIntent.ts defines: MarketIntent interface (id, actor, regionId, goodId, side, purpose, quantities/budgets, inventory buckets); comprehensive validation covering all specification constraints (non-negative/finite quantities, BUY maxSpend, SELL minimumReserveQuantity, ProductionUnit bucket routing [INPUT/OUTPUT/INVESTMENT for specific purposes], actor ownership validation); BudgetCommitmentLedger interface tracking actor+currency+envelope commitments with commitment tracking, overcommitment prevention, and reusable-envelope release. src/simulation/marketIntent.test.ts: 35 comprehensive tests covering valid MarketIntent creation for all actor types (Clan, State, ProductionUnit) and purposes (CONSUMPTION, INPUT, INVESTMENT, PUBLIC_PROCUREMENT, INVENTORY_REBALANCE); validation rejection of non-finite/negative values; budget ledger operations (creation, commitment accumulation, envelope isolation, overcommitment prevention, partial/full release, reusability handling); ProductionUnit-specific bucket routing and validation. src/simulation/tickOrchestrator.ts extended: TickContext now includes budgetLedger field (initialized empty per tick); phase handlers in M3+ can manage budget commitments through the ephemeral ledger without mutation of persistent WorldState. All acceptance criteria met: MarketIntent schema fully defined with all required/optional fields; validation rejects non-finite/negative quantities and invalid constraints; BUY maxSpend and SELL minimumReserveQuantity validated; budget ledger prevents overcommitment within envelope limits; ProductionUnit intents use explicit INPUT/OUTPUT/INVESTMENT buckets; static-fixture test suite covers all constraint classes with 35 tests. TypeScript verification: 322 tests passed (28 files), typecheck clean, build succeeded. C#/.NET: 45 tests passed, build clean (REQ-MIGRATION-003 maintained)."
REQ-MARKET-002,IMPLEMENTED,270,316,e3b747ef310957b99904977ad88ae5035ed5ef25,"Foundation (PR #250): Phase-6 price formation with persistent market expectations (Handoff/04 section 9): repriceGoodInPhase6() bounded log-space repricing formula, updateMarketExpectations() EMA updates. Specification ownership: Handoff/03 section 4 defines canonical market baseline values. PR #250 implemented formula and EMA mechanics correctly but used non-canonical defaults. Fix (PR #316, Issue #270): Corrected five market configuration defaults in src/config/simulationConfig.ts to match Handoff/03 section 4: shortageSignalWeight (0.5 → 0.65), inventorySignalWeight (0.5 → 0.35), basePriceAdjustmentSpeed (0.1 → 0.12), maxAbsoluteLogPriceMovePerTick (0.1 → 0.18), expectationAlpha (0.2 → 0.25). Added six regression tests in src/config/validation.test.ts verifying each default matches specification. All acceptance criteria met: Phase-6 repricing formula unchanged, all five defaults now match specification exactly, canonical baseline targetInventoryCoverageTicks (1.0) preserved. Verification: TypeScript 481 tests passed (including new canonical-market-defaults suite), typecheck clean, build succeeded; C#/.NET 45 tests passed, build clean (REQ-MIGRATION-003 maintained)."
REQ-CORE-005,IMPLEMENTED,188,247,a692ae3e38b310efea59bb10fdc41ce1488e526a,"PendingTransitions contract ensuring Phase-14 decisions cannot mutate current-tick state. Interface defines jurisdictionChanges, stateCreations, policyChanges, monetaryPolicyChanges arrays. Helper functions manage transitions immutably; only changes with activateTick = currentTick are active (CORE-T7). 17 tests prove N+1 causality: changes queued in Phase-14 activate only in tick N+1 or later, never in tick N. WorldState.pendingTransitions initialized empty at genesis. TypeScript verification: 304/304 tests passed, typecheck green, build succeeded (7015bc9). REQ-CORE-005 ready for Phase-1 activation logic in M3+."
REQ-ACCEPTANCE-003,IMPLEMENTED,253,254,3e77cf588b53d619a5dc20dadf168c6337f15dd3,"Automated test suite (src/simulation/acceptance-003-zero-flow-reconciliation.test.ts) with 12 comprehensive tests: baseline construction, 100+ tick zero-flow reconciliation health, reconciliation tolerance configuration (SimulationConfig.numeric.reconciliationRelativeTolerance = 1e-9), unmatched delta diagnostic structure, deterministic behavior across runs, phase trace integration. All tests pass (334/334 TypeScript, 45/45 C#/.NET). Zero-flow reconciliation passes for no-op scenario across 100+ ticks; reconciliation error structure ready for M3+ economic ledger records."
REQ-MARKET-003,IMPLEMENTED,251,293,bf526b33abcd7caf6188237dad4756273850266e,"Deterministic proportional local clearing primitive with MarketAllocation schema, stable residual correction, and two-pointer concrete matching for atomic transaction bundle production. src/simulation/marketClearing.ts implements proportional clearing for one region+good+pass, preventing floating-point rounding errors via stable-ID correction, and produces identical allocations regardless of input insertion order. src/simulation/marketClearing.test.ts: 19 comprehensive tests covering proportional splits, excess supply/demand, zero-flow edge cases, shuffled-insertion determinism, tax-aware pricing validation, and stable ID ordering. Acceptance criteria verified: seller/buyer fills sum to cleared quantity within tolerance; no fill exceeds constraints; residual correction stable-ID ordered; shuffled intent insertion produces identical normalized allocations; all specification constraints verified. TypeScript: 439 tests passed, typecheck clean, build succeeded. C#/.NET: 45 tests passed, build clean (REQ-MIGRATION-003 maintained). REQ-MARKET-003 ready for M3 market-phase integration."
REQ-MARKET-004,IMPLEMENTED,481,497,f2f507048cbaf878d018ac66f6f44f05b07379aa,"Two pull requests contributed. PR #301 (Issue #255, merged f891da9ddb38468f15a7def7982663876cc27afc) built the settlement layer: MARKET_SALE and CONSUMPTION_TAX transaction schemas, createMarketSaleTransaction / createConsumptionTaxTransaction / preflightMarketSettlement / executeMarketSettlement in marketSettlement.ts, the TaxPolicyProvider port and computeConsumptionTax, the additive EconomicTransaction identity fields (transactionId / bundleId / originatingTransactionId / fxSettlementId), MarketAllocation.regionId, and MTFX-I1 / MTFX-I2 coverage. PR #497 (Issue #481) closed the gap that left MTFX-T4 unproven on the production path: createPhase8Handler pinned taxRate = 0.1 and collectionEfficiency = 1.0 in its own body so no fixture could inject either value, and computeGrossUnitPrice returned sellerNet * (1 + rate), dropping the collection efficiency that Handoff/04 section 2 puts in buyerGross = sellerNet + sellerNet * rate * collectionEfficiency. Phase 8 now consumes an injected TaxPolicyProvider and feeds one policy read into affordability, allocation taxation, settlement and telemetry; an uncontrolled Region reads zero for both; out-of-[0,1] reads are refused; no fallback policy exists. Test that fails without the change: src/simulation/phase8MainMarketClearing.test.ts, the MTFX-T4 fixture with sellerNet 10, rate 0.20, collectionEfficiency 0.40, desiredQuantity 1 and maxSpend 10.9 - buyer gross 10.8, collected tax 0.8, one fully cleared unit, and the assessed-but-uncollected 1.2 left with the buyer; measured failing against both the 10%/100% path and an efficiency-dropping gross formula. Verification on 479d000: npm run typecheck passed, npm test passed (648), npm run build passed, dotnet build --configuration Release passed, dotnet test --configuration Release passed (45). REQ-MIGRATION-003 maintained."
REQ-ACCEPTANCE-001,IMPLEMENTED,232,263,7808a9175f7fc3b13b30878d194bce8977ce10c0,"Automated test suite (src/simulation/acceptance-001-stock-preservation.test.ts) with 9 comprehensive tests: baseline scenario construction and frozen WorldState property (2), 100+ tick no-op scenario stock preservation (5), documented interface usage without undocumented mutation paths (1), independent seed handling (1). Test coverage: executes 120+ consecutive no-op ticks with no-op phase handler; verifies reconciliationErrors is null for each tick (stocks preserved); validates only time-derived counters (tick number) change; confirms SimulationConfig.numeric.reconciliationRelativeTolerance (1e-9) is applied; checks TickContext carries public documented properties (tick, phase, transactions, rngSeed); proves all entry points use only public APIs. All acceptance criteria met: Baseline scenario builds without error and produces frozen WorldState; 100+ no-op ticks execute and preserve all stocks exactly (no transactions, zero-flow reconciliation passes); Time-derived counters increment correctly; Tolerance-based reconciliation uses only SimulationConfig.numeric.reconciliationRelativeTolerance (1e-9 default); No milestone-local epsilon or undocumented production mutation paths required. Verified across multiple independent seeds (42, 123, 999) proving isolated stock preservation. TypeScript verification: 360 tests passed (31 files, including 9 new), typecheck clean, build succeeded. C#/.NET: 45 tests passed, build clean (REQ-MIGRATION-003 maintained). REQ-ACCEPTANCE-001 ready for M2 gate closure."
REQ-MARKET-005,IMPLEMENTED,427,477,bdabafcb3f80ed8d4183f8e3a2752d004ed45705,"Foundation (PR #334, merged c1a45ad) delivered LocalMarketTelemetry interface and LocalMarketTelemetryBuilder with canonical quantityEpsilon. PR #339 added integration test scaffold. PR #352 (Issue #341, merged edde27b4da33ef06e7a795ab10104f3c0315233c) fixes production-path blocker: phase8MainMarketClearing.ts handler now calls computeLocalClearing() to perform real market clearing; telemetry values derive from actual clearing results instead of fabricated fixtures. PR #387 (Issue #386, merged c1fd9b47f784ee1b37c0b7ec69d393cf1effa885) added two golden-gate tests in acceptance-req-market-005-phase8-integration.test.ts proving all 11 required section-33 fields are finite/structurally valid and match a seeded shortage fixture's actual clearing results, and identified a genuine acceptance gap in the telemetry on/off comparison. PR #414 (Issue #412, merged 7a4faaf8fe4072001781dececa9df1286d8ba6c7) closed the allocation half of that gap: computeLocalClearing() now runs identically regardless of collectTelemetry, and the on/off test asserts context.marketAllocations deep-equality in addition to computeTickHash(). It did not compare authoritative wallets, inventories, or context.currentLedger -- TypeScript 555 tests passed, typecheck clean, build succeeded; C#/.NET 45 tests passed (REQ-MIGRATION-003 maintained). Issue #416 found that gap made the IMPLEMENTED status overstated (computeTickHash() hashes only tick/configVersion/scenarioId/seed/phaseTrace/transactionCount; context.currentLedger is never written by this fixture's Phase-8 handler either way). A first revision of PR #426 tried to close it by settling both runs' already-equal marketAllocations through the real executeMarketSettlement() transaction-construction path and comparing the resulting synthetic wallet/inventory snapshots; the ACCEPTOR (CHANGES_REQUESTED, head 2ac5dce) and the external QA voice both correctly found this tautological -- executeMarketSettlement() is a pure function of the allocation alone, so feeding two already-asserted-equal allocation arrays through it produces equal output by construction, exercising no production path that could actually diverge on the telemetry toggle. The corrected revision of PR #426 removes that proof and instead demonstrates, directly against the real production WorldState object, that Phase-8 does not mutate WorldState (clans, cohorts, production units, or markets) under either telemetry setting, with a negative control proving the comparison used is sensitive to a real injected divergence. It also documents why no stronger proof is available yet: WorldState carries no live/mutable wallet or inventory representation at all today -- ClanState/CohortState/ProductionUnitState hold only identity and immutable seed data, the only stock ledger is the immutable opening worldGenesisLedger, and the spec's own settlement-mutation boundary (MarketSettlement.executeAllocation(world, ctx, allocation), Handoff/04 section 35) does not exist in this codebase (confirmed via repository-wide search). Wiring that boundary is tracked as a new prerequisite, Issue #427; REQ-MARKET-005's canonical-stock-neutrality clause (Issue #416 acceptance criteria 1-3) cannot be proven as anything but WorldState-untouched until it lands. Per Issue #416's own Scope (""keep or return the requirement to PARTIAL until the permanent stock-neutrality clause is proved""), this row is returned to PARTIAL rather than continuing to claim IMPLEMENTED. Verification: TypeScript 566 tests passed (40 files; 2 new/replaced), typecheck clean, build succeeded; C#/.NET 45 tests passed (REQ-MIGRATION-003 maintained). PR #475 (Issue #427) lands the prerequisite Issue #416 was blocked on, as a bounded first slice. WorldState now carries live wallet/inventory stock on the actor states that canonically own it -- ClanState.treasury only (no physical inventory; Handoff/01 5.3/5.4/7), CohortState.wallet + householdInventory, ProductionUnitState.wallet + three distinct INPUT/OUTPUT/INVESTMENT inventories, StateState.treasury + publicInventory -- and MarketSettlement.executeAllocation(world, ctx, allocation) (src/simulation/marketSettlementTransition.ts) exists for the first time, applying steps 1-5 of the Handoff/04 section-10 atomic bundle to that stock and returning the resulting WorldState (ADR 0007). Live stock is seeded from the completed genesis ledger through the shared actorRefKey that genesisReconciliation.ts now also uses, so opening and live stock address an owner through one mapping by construction (Issue #427 criterion 5, relocated from Issue #448 by the ACCEPTOR verdict on PR #459). Money conservation (buyer gross debit = seller net receipt + collected tax) and goods conservation (seller OUTPUT decrease = buyer household increase) are proven against a real WorldState built by buildInitialWorld(baselineScenario, ...), not a test-local synthetic map -- the gap that forced every prior MTFX-I1/I2 proof to build its own wallet maps. Five refusal regressions prove settlement fails rather than inventing an endpoint (Clan goods endpoint, ProductionUnit GENERAL bucket, ProductionUnit bucket on a Cohort, MonetaryAuthority counterparty, collected tax with no destination State), each asserting the world is unchanged, with a State publicInventory positive control showing the GENERAL refusals are about ownership rather than the literal string. This does NOT close the REQ-MARKET-005 canonical-stock-neutrality clause and the row stays PARTIAL: executeAllocation is not yet called by phase8MainMarketClearing.ts (Issue #427 criterion 2's wiring half) because every existing M3 fixture trades as CLAN buyer and seller with a GENERAL bucket, which R235 calls implementation drift and which has no canonical stock endpoint; converting those fixtures is a separate unit of work. Criterion 4's telemetry on/off post-settlement regression depends on that wiring and is not attempted. Issue #427 stays open, narrowed to those two items. Verification at 70749b4: TypeScript 608 tests passed (41 files, 14 new), typecheck clean, build succeeded; C#/.NET build clean and 45/45 tests passed (REQ-MIGRATION-003 maintained). PR #477 (Issue #427) wires the settlement half and promotes this row to IMPLEMENTED. applyMarketSettlementTransition(world, context) (src/simulation/marketSettlementTransition.ts) folds executeAllocation() over every realized MAIN-pass allocation Phase-8 produced, in the Handoff/04 section-36 stable order computeLocalClearing() already emitted them in, and returns the settled WorldState. It sits beside applyMarketStateTransition() rather than inside createPhase8Handler() because a PhaseHandler returns a TickContext and executeTick() holds one WorldState immutable across all sixteen phases (REQ-CORE-004), so a phase handler structurally cannot hand a mutated world back; Handoff/04 section 35 asks for exactly this split (planning returns deltas, mutation belongs in an explicit settlement function) and ADR 0007 already fixed executeAllocation() as world-in/world-out. Two defects that made Phase-8's allocations unsettleable are fixed in phase8MainMarketClearing.ts: marketCurrencyId was the constant ""cur:reserve"" that no actor holds, and consumption tax was assessed with destinationStateId null, which executeAllocation() refuses because tax debited from a buyer and credited to nobody destroys money inside a transfer. Both now come from the canonical RegionState (settlement currency; controller as the treasury), and an uncontrolled region assesses zero consumption tax (HANDOFF-REPAIR-006), with the one rate feeding both affordability and the recorded gross price. The M3 Phase-8 fixtures in acceptance-req-market-005-phase8-integration.test.ts were converted from CLAN-against-CLAN on a GENERAL bucket -- implementation drift per R235, naming a stock endpoint a Clan does not own -- to a PRODUCTION_UNIT seller debiting OUTPUT against a COHORT buyer crediting its single household inventory. Three new regressions run against a real buildInitialWorld(baselineScenario, ...) world driven by executeTick(): (1) every realized allocation settles onto the canonically-owned endpoints, with buyer gross debit = seller net receipt + collected tax, world-wide money and goods totals unchanged, and no stock driven negative; (2) telemetry on and telemetry off produce identical post-settlement clans, cohorts, productionUnits, states, markets and currentLedger -- the canonical-stock-neutrality clause of this requirement, and the gap Issue #416 could not close before a settlement boundary existed; (3) a negative control perturbing one settled wallet by a single unit proves that comparison fails on a real divergence while the allocations still compare equal, so criterion (2) is not vacuous. R235 stated this row remains PARTIAL until the real Phase-8 settlement and telemetry-neutrality evidence merges; that evidence is this pull request. Judgement call recorded for the ACCEPTOR: Issue #427 criterion 2 is written as ""called by Phase-8"" and this is the settlement boundary applied to Phase-8's output instead, for the structural reason above. Remaining, filed separately and not claimed here: the acceptance-004-m3-golden-gate.test.ts Phase-6/Phase-8 dispatch fixtures still trade CLAN against CLAN on a GENERAL bucket and never settle. Verification at a681fe2 (this branch's only code commit; the ledger commit that follows adds only this CSV and the document generated from it, which none of the five suites reads): TypeScript 611 tests passed (41 files, 3 new), typecheck clean, build succeeded; C#/.NET restore and Release build clean (0 warnings, 0 errors) and 45/45 tests passed (REQ-MIGRATION-003 maintained)."
REQ-ACCEPTANCE-004,IMPLEMENTED,478,506,560384ab63b5d3675dcfbb08e78cf42c3f35ff7a,"""Foundation (PR #337) + repair (PR #344, merge e0d2d5f) + strengthened settlement evidence (PR #349, merged 2fb6ea004ff64ef0e054914752c29480710f97f7). PR #337 delivered test framework and integrated computeLocalClearing clearing. PR #344 replaced hand arithmetic with canonical primitives: MTFX-T1 price-formation path, MTFX-I1 transaction-record path, MTFX-I2 clearing validation, MTFX-T3 tax-affordability path. PR #349 (Issue #348) strengthens MTFX-I1 and MTFX-I2: both now execute authoritative settlement mutations on concrete wallet/inventory objects, proving money conservation identity (buyer gross debit = seller net receipt + collected tax) and goods conservation identity (seller decrease = buyer increase) through before/after balance verification. MTFX-I1: distinct buyer/seller wallets initialized 100 units each, settlement mutates wallets and state treasury, verifies conservation through delta analysis, rejects negative balances. MTFX-I2: distinct buyer/seller inventories initialized, settlement mutates inventories, proves seller decrease = buyer increase, rejects negative inventory, verifies total goods conserved. Both tests now verify canonical settlement path execution with authoritative state mutations, not only transaction record arithmetic. TypeScript: 533 tests passed (all 38 files), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). Remaining work: MTFX-T2..T6 (extreme scenarios, determinism, boundary conditions), MTFX-I3..I6 (negative balance/overdraft/market-stock edge cases), orchestration golden-gate scenario. REQ-ACCEPTANCE-004 remains PARTIAL until all enumerated acceptance artifacts complete."" PR #417 (Issue #268) adds the next bounded slice: MTFX-T2 proves repriceGoodInPhase6() bounds every single-tick log-price move to <= exp(maxAbsoluteLogPriceMovePerTick) under 50 ticks of sustained extreme excess demand and, symmetrically, extreme excess supply, and that the price reaches but never crosses the configured ceiling/floor. The ACCEPTOR (PR #417 reviews) and the researcher (PR #417 comment) both found the PR's original second test mislabeled as canonical MTFX-I3 (Handoff/04 SS38 defines I3 as fill conservation, sum(seller fills) == sum(buyer fills) == clearedQuantity, still outstanding) and vacuous on the wallet side (seller-stock cap was always tighter than the wallet cap in the one fixture, so a regression deleting the wallet-affordability cap would not have failed it). PR #417 was corrected in place: the describe block is relabeled MTFX-I4 (canonical 'no BUY settles above maxSpend; no SELL settles above sellable quantity') and a second, complementary fixture was added where the buyer's wallet (3 units afforded) is the binding constraint against the seller's ample stock (100,000 units), calling the same real exported computeSellableQuantity/computeEffectiveDemand/computeLocalClearing primitives, so both the seller-stock-bound and buyer-wallet-bound halves of I4 are now independently exercised and neither seller inventory nor buyer wallet balance is ever driven negative in either case. TypeScript: 559 tests passed (40 files), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). Remaining work: MTFX-T4..T6, canonical MTFX-I3 (fill conservation) and I5..I6, orchestration golden-gate scenario; the file's own header comment and Issue #268's I1..I6 checklist still use a numbering that has drifted from the canonical Handoff/04 SS38 list and should be reconciled in a dedicated pass before further slices are claimed. REQ-ACCEPTANCE-004 remains PARTIAL until all enumerated acceptance artifacts complete. PR #419 (Issue #268) adds the next bounded slice: canonical MTFX-I3 fill-conservation (Handoff/04 SS38: sum(seller fills) == sum(buyer fills) == cleared quantity), proven by a multi-seller (3) / multi-buyer (2) proportional-clearing fixture where cleared quantity is strictly bound by total demand (75 of 100 total supply), forcing multi-lot two-pointer matching. The test calls the real exported computeLocalClearing() primitive and compares its per-seller and per-buyer summed output against expected fills computed independently in the test from the documented proportional formula (not read back from the allocations under test), then asserts sum(seller fills) == sum(buyer fills) == cleared quantity within quantityEpsilon. The file header comment's MTFX-I3 bullet, previously describing a non-canonical local numbering, was corrected to the canonical Handoff/04 SS38 wording. TypeScript: 560 tests passed (40 files), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). Remaining work: MTFX-T4..T6, MTFX-I5..I6, and the full local-shortage orchestration golden-gate scenario; the file's MTFX-I1/I2 describe block labels still use this file's earlier local numbering rather than canonical Handoff/04 SS38 meanings (documented inline, not fixed here to keep this PR bounded to the one outstanding item named on the ledger). REQ-ACCEPTANCE-004 remains PARTIAL until all enumerated acceptance artifacts complete. Per the ACCEPTOR's CHANGES_REQUESTED verdict on PR #419 (head 3ec198a), the MTFX-I3 block's per-participant and three-way-identity checks were tightened: the toBeCloseTo(..., 6) calls (looser than quantityEpsilon by roughly 50x) were replaced with explicit Math.abs(actual - expected) < quantityEpsilon assertions for the per-seller and per-buyer expected-fill checks, for sumSellerFills vs clearedQuantity, for sumBuyerFills vs clearedQuantity, and for grandTotal vs clearedQuantity, so every leg of the claimed three-way identity is now checked at the canonical tolerance rather than only the seller-sum-vs-buyer-sum leg. PR #424 (Issue #268) adds the next bounded slice: MTFX-T5 (Handoff/04 §39, ""Proportional seller/buyer rationing conserves quantity and is insertion-order invariant""), proven by running the existing MTFX-I3 multi-seller (3) / multi-buyer (2) shortage fixture (sellable 50/30/20, effective demand 40/35, cleared quantity 75) through computeLocalClearing() three times with the identical intents in three different input array orders (forward, fully reversed, and a non-reversed shuffle) and asserting bit-identical per-participant summed fills and conserved total cleared quantity across all three orderings. The 20-unit seller's proportional share (75 x 20 / 100) is not exactly representable in binary floating point, so the residual-correction pass in marketClearing.ts actually executes rather than being a no-op, making the test sensitive to a regression that keyed correction/matching order on input array position instead of the stable actor/intent ID. TypeScript: 564 tests passed (40 files), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). Remaining work: MTFX-T4, MTFX-T6, MTFX-I5, MTFX-I6, and the full local-shortage orchestration golden-gate scenario. REQ-ACCEPTANCE-004 remains PARTIAL until all enumerated acceptance artifacts complete. PR #429 (Issue #268) adds the next bounded slice: MTFX-T4 (Handoff/04 section 1 / section 39, ""An injected taxPolicy fixture with collectionEfficiency strictly between 0 and 1 credits only collected tax, leaves assessed-but-uncollected tax with the buyer, and proves M3 does not assume collectionEfficiency = 1 or require M6 policy dynamics""), proven against the real computeLocalClearing() path with a fixture where assessedTaxRate=0.25 and collectionEfficiency=0.4 (assessedTaxPerUnit=2.5, collectedTaxPerUnit=1.0): the buyer's maxSpend is sized to exactly afford the desired quantity at the collected-tax gross price (11.0) but would only afford 44 of 50 desired units at the full-assessed-tax price (12.5), so the full 50-unit clear itself proves affordability used only collected tax. The test asserts allocation.consumptionTaxAmount equals quantity times collected tax per unit (not assessed), cross-checks the standalone computeConsumptionTax() settlement helper agrees with the clearing-layer split, then executes the real executeMarketSettlement() path and proves the assessed-but-uncollected remainder (75 of the full 125 assessed) is debited from nobody, credited to nobody, and appears in neither the MARKET_SALE nor CONSUMPTION_TAX transaction: total transacted money equals seller net receipt plus collected tax only. TypeScript: 567 tests passed (40 files), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). Remaining work: MTFX-T6, MTFX-I5, MTFX-I6, and the full local-shortage orchestration golden-gate scenario. REQ-ACCEPTANCE-004 remains PARTIAL until all enumerated acceptance artifacts complete. PR #431 (Issue #268) adds the next bounded slice: MTFX-T6 (Handoff/04 section 38/39, ""Buyer maxSpend and seller reserve are never violated after floating residual correction""), proven against the real computeLocalClearing() primitive with two fixtures (200 sellers/2 buyers, and the symmetric 200 buyers/2 sellers) sized -- confirmed by direct floating-point computation -- so the provisional-fill sum residual genuinely exceeds quantityEpsilon and applyResidualCorrection's correction branch actually executes, unlike the MTFX-T5 fixture (75 * 20 / 100 divides exactly, so its correction gate never fires). Each fixture asserts every participant's realized fill/spend after correction stays within their own real sellable reserve or maxSpend beyond epsilon tolerance. TypeScript: 569 tests passed (40 files, 2 new), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). Remaining work: MTFX-I5, MTFX-I6, and the full local-shortage orchestration golden-gate scenario. REQ-ACCEPTANCE-004 remains PARTIAL until all enumerated acceptance artifacts complete. PR #433 (Issue #268) adds the next bounded slice: canonical MTFX-I6 (Handoff/04 §38, ""Market owns no cash or physical goods""), proven against the real computeLocalClearing()/executeMarketSettlement() production path with a two-seller/two-buyer taxed shortage fixture: every resulting MARKET_SALE and CONSUMPTION_TAX transaction settles only between CLAN/STATE actors (ActorRef is a closed union with no MARKET variant), confirmed by a runtime detector that also correctly flags a fabricated market-owned transaction as a negative control, plus a structural check that LocalMarketState carries no wallet/inventory field. Also corrected this file's stale header-docstring MTFX-I4/I5/I6 bullets to match the canonical Handoff/04 §38 numbering already used by the I3/I4 describe blocks. TypeScript: 570 tests passed (40 files, 1 new), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). Remaining work: MTFX-I5 under the corrected canonical numbering (price changes at most once per tick and stays within configured bounds -- an orchestration-level invariant, not yet implemented), and the full local-shortage orchestration golden-gate scenario. REQ-ACCEPTANCE-004 remains PARTIAL until all enumerated acceptance artifacts complete. PR #435 (Issue #268) adds a bounded slice of canonical MTFX-I5 (Handoff/04 §38, ""Price changes at most once per tick and stays within configured bounds""): only the price-bounds half is proven, with a test showing repriceGoodInPhase6() stays within the configured max log-step and price floor/ceiling when shortage pressure and inventory-gap pressure combine in a single call, reaching the ceiling under sustained combined pressure. A second test proves computeLocalClearing() is a pure pass-through for whichever price it is given -- run once at a mild-shortage price1 and once at a distinctly larger price2, with allocations tracking whichever price is actually passed in -- but per the ACCEPTOR's CHANGES_REQUESTED verdict on PR #435 (head 68427ba), this is necessary but not sufficient evidence for MTFX-I5's ""at most once per tick"" half: it never exercises or observes a real per-tick Phase-6 -> Phase-8 orchestration boundary (none exists yet; repriceGoodInPhase6 and computeLocalClearing are not wired into a single dispatchable per-tick pipeline), so a regression that repriced twice in one tick and fed the second result to Phase 8 would still leave it green. That once-per-tick orchestration-timing half is corrected to remain outstanding rather than claimed proven. TypeScript: 572 tests passed (40 files, 2 new), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). Remaining work: MTFX-I5's once-per-tick orchestration-timing half, and the full local-shortage orchestration golden-gate scenario. REQ-ACCEPTANCE-004 remains PARTIAL until all enumerated acceptance artifacts complete. PR #436 (Issue #268) adds the outstanding local-shortage golden scenario (Handoff/04 §40 scenario A) as a real end-to-end, multi-tick integration test: three buyer clans with fixed, never-replenished money endowments and a shocked, fixed per-tick seller offer (drawn from an ample true regional stock, so ownership itself is never the binding constraint) run through 8 ticks of the real production pipeline in sequence against the same evolving state -- repriceGoodInPhase6() -> computeLocalClearing() -> preflightMarketSettlement()/executeMarketSettlement() -- mutating authoritative wallets/inventories/treasury exactly as the existing MTFX-I1/I2/T4 blocks do per-allocation, with updateMarketExpectations() feeding the next tick's repricing. Proves price rises boundedly (every tick's move within exp(maxAbsoluteLogPriceMovePerTick) and within [minimumPrice, maximumPrice], peak price strictly above the start), effective demand rations under budget pressure (at least one buyer's own wallet, not only physical scarcity, caps their effective demand below desired), and total money (all buyer wallets + seller wallet + State treasury) and total goods (seller remaining stock + all buyer inventories) are exactly conserved across the whole run. TypeScript: 572 tests passed (40 files; net zero test-count change, one placeholder scenario-construction test replaced by the real scenario), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained).  Per the ACCEPTOR's CHANGES_REQUESTED verdict on PR #436 (head 3e792aac938570f3bdcb415db1d51837a0d4a1d1), corroborated independently by the researcher and by SLOPSTER on the same head: the tick loop's Phase-6/Phase-8 ordering was inverted relative to Handoff/04 §9 (it cleared and settled at the current price, then repriced for next tick, so every tick's trades cleared one tick late relative to that tick's own demand/supply). Corrected in place: each tick now (1) computes that tick's own D/S from current wallets/state, (2) calls repriceGoodInPhase6() using the expectation state carried from the previous tick to get that tick's price, (3) clears and settles at that same-tick price, and (4) calls updateMarketExpectations() only afterward, from that tick's own realized aggregates, to feed the next tick's Phase 6. All scenario-level conservation, bounded-repricing and budget-rationing assertions are unchanged and still pass. This is a bounded slice: MTFX-I5's once-per-tick orchestration-timing half remains separately outstanding, blocked on a real per-tick Phase-6 -> Phase-8 dispatch pipeline that does not exist yet. REQ-ACCEPTANCE-004 remains PARTIAL until that half and any other enumerated acceptance artifacts complete. PR #438 (Issue #268) closes the previously outstanding once-per-tick orchestration-timing half of MTFX-I5: createPhase6Handler (src/simulation/phase6MarketPriceFormation.ts) reprices via repriceGoodInPhase6() only when context.phase === 6, writing the result into a new TickContext.marketPrices field; createPhase8Handler now reads that field before falling back to world.markets, and a new composePhaseHandlers() utility lets both run through the real executeTick() phase loop as one dispatch pipeline. A new test in acceptance-004-m3-golden-gate.test.ts's MTFX-I5 describe block drives that composed pipeline through 5 real executeTick() calls and proves, against the actual dispatch (not a hand-rolled loop): a fixture-intents call counter gated inside the phase===6 guard equals the tick index after every call (repricing executes exactly once per tick); every settled allocation's sellerNetUnitPrice equals that same tick's context.marketPrices entry (Phase-8 uses exactly the Phase-6 price, not an independently re-read world price); and price stays within the configured max-log-step and floor/ceiling bounds throughout. A negative control (Phase-8 alone, no Phase-6 handler composed) settles at the world fallback price instead, showing the price-sharing proof is not coincidental. TypeScript: 573 tests passed (40 files, 1 new), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). With this, all of MTFX-T1..T6, MTFX-I1..I6 (canonical Handoff/04 §38 numbering) and the local-shortage golden scenario (Handoff/04 §40 scenario A) are proven; REQ-ACCEPTANCE-004 is promoted to IMPLEMENTED. PR #441 (Issue #440) closes the final MTFX-I5 orchestration gap: adds applyMarketStateTransition() as the explicit production boundary that persists each tick's Phase-6 price and post-Phase-8-MAIN MarketExpectationState observation into WorldState.markets between real executeTick() calls, replacing PR #438's test-owned getFixtureCurrentPrice/getFixtureExpectation cross-tick closures. Phase-8's MAIN-pass effectiveDemand/offered/cleared aggregates are now computed unconditionally in a new TickContext.marketClearingAggregates field (previously gated behind collectTelemetry), so this authoritative expectation transition never depends on the non-authoritative REQ-MARKET-005 telemetry toggle. The rewritten multi-tick dispatch test seeds a market into WorldState and persists state via applyMarketStateTransition() between ticks instead of fixture memory, asserting the persisted expectation observationCount increments once per tick; a new negative-control test proves that skipping the persistence call between ticks leaves price and expectation observably stuck. TypeScript: 574 tests passed (40 files, 1 new), typecheck clean, build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). PR #506 (Issue #478) is a fixture-identity repair, not new acceptance coverage: the two Phase-6/Phase-8 dispatch fixtures in acceptance-004-m3-golden-gate.test.ts (the composed once-per-tick dispatch test added by PR #438/#441, and its no-persistence negative control) still traded a CLAN seller against a CLAN buyer on a GENERAL inventory bucket, on a synthetic region that was not in world.regions. R235 (ANSWERS_TO_IMPLEMENTER.md / CODE_RUNTIME_QA_M3_16) calls that implementation drift -- a Clan owns a treasury and no physical goods at all (Handoff/01 SS5.3/5.4/7) -- and resolveGoodsEndpoint() in marketSettlementTransition.ts refuses such an allocation outright. PR #477 (Issue #427) converted the seven Phase-8 fixtures in acceptance-req-market-005-phase8-integration.test.ts and deliberately left these two alone because they never call settlement and so did not throw. Both now draw their counterparties and their region from a real buildInitialWorld(baselineScenario, ...) world through a new canonicalDispatchCounterparties() helper: a PRODUCTION_UNIT seller offering from the OUTPUT inventory that holds its food against a funded COHORT buyer whose single household inventory owns consumed food, in a region whose RegionState.controllerStateId is non-null -- so the settlement currency and consumption-tax destination Phase 8 reads off the canonical RegionState both resolve as they would in production (they previously resolved to no controlling State and assessed zero tax). Every assertion about once-per-tick dispatch, Phase-6/Phase-8 price sharing, bounded repricing and the persistence boundary is unchanged in meaning and still passes. REQ-ACCEPTANCE-004 stays IMPLEMENTED; contributing pull requests are #337, #344, #349, #417, #419, #424, #429, #431, #433, #435, #436, #438, #441 and #506. TypeScript: typecheck clean, 672 tests passed (46 files), build succeeded. C#/.NET: build clean, 45 tests passed (REQ-MIGRATION-003 maintained). PR #557 (Issue #347) repairs the remaining MTFX-I2 proof gap left by those earlier fixture-map checks: the focused acceptance test now builds the canonical baseline WorldState, clears a non-zero ProductionUnit OUTPUT sale to a Cohort household, applies the allocation through executeAllocation(world, context, allocation), and proves on authoritative stock that seller decrease = buyer increase = allocation.quantity with total goods conserved. The same assertion fails on a bypassed seller mutation and on a reversed buyer mutation, providing sensitive negative controls. Exact-head CI run 35293863449 on 884d98f1913e6648f2ebc3051c85b7f20565f57f passed all required gates before this evidence-only reconciliation; the requirement remains IMPLEMENTED and its existing #506 merge provenance is preserved until this corrective PR merges."
REQ-VISUALIZATION-007,IMPLEMENTED,501,504,bb30bc4cee37ca83f144c4bd07349a0356f8d6ec,"README/public-documentation conformance for M3. Contributing merged pull requests: #358 (Issue #355) rewrote the root README for the canonical TypeScript runtime, the M3 state, the Pages link, the build/typecheck/test/run commands and the legacy C# as a reference oracle; #366 (Issue #361) corrected README M3 completion claims to match ledger status; #484 (Issue #445) repaired six public-text defects (ephemeral MarketIntent; the per-tick maxAbsoluteLogPriceMovePerTick bound rather than a ""daily"" one; the M2 ledger scope; M4/M5/M8 milestone ownership; REQ-MARKET-005 and REQ-ACCEPTANCE-004 recorded IMPLEMENTED; and the browser-capable-versus-M11-observatory distinction from SPEC_CHANGELOG RUNTIME-001). #484 left this row PARTIAL because the registry acceptance covers the README *and its directly linked public docs*, and both linked reference articles carried open conformance defects: Issue #446 (merged as #486, bd61a157012c4af0d252789c80c42e48056b5194) and Issue #447 (merged as #489, 838db1bc7ad4356c1603948678f302d2d2293d89). Both are now on master and REQ-VISUALIZATION-008 is IMPLEMENTED. #499 (Issue #496, this pull request) repairs the last recorded defect class: after #491 landed REQ-VISUALIZATION-006, the README still said the Pages deployment showed the legacy viewer and the M1/M2 previews, still offered ""the current M2 Milestone Preview"" as the viewer link, still said REQ-VISUALIZATION-006 was ""not yet started"", and still called the generated docs/spec/IMPLEMENTATION_STATUS.md authoritative instead of the docs/spec/implementation_status.csv ledger it is generated from. The README now describes the consolidated M3 LocalMarket experience as the Pages default with M0-M2 and the legacy run viewer behind the collapsed history disclosure that docs/index.html actually renders, names the CSV as the authoritative per-requirement record and the Markdown as presentation only, and makes no claim that M3 has closed - milestone release stays mechanical in release-tag.yml. Test that fails without the change: src/diagnostics/readme-conformance.test.ts (7 tests) pins each mechanically decidable README claim to the artifact that decides it - every relative link resolves on disk; every REQ identifier named in the README (including REQ-MARKET-001..005 range shorthand) exists in the ledger; no README block calls a requirement outstanding that the ledger records IMPLEMENTED; the word authoritative attaches to implementation_status.csv and not to the generated table; every paragraph carrying the Pages URL names M3; docs/index.html leaves #m3-preview-body in the default view while #m0/#m1/#m2-preview-body and the legacy viewer mount #app sit inside the <details> disclosure; and every documented npm run script exists in package.json. Mutation-proved against master's README (git show master:README.md): 3 of the 7 fail there - the IMPLEMENTED-called-outstanding check, the authoritative-ledger check and the Pages-milestone check - and all 7 pass on this branch. Prose accuracy as a whole remains unverifiable by test; the standing control is that a conformance defect is filed as an Issue, as #445 and #496 were. Documentation and test only: no runtime, formula, schema, default, phase-order, milestone-mechanics or v1-scope change, and docs/spec/mirror/ is untouched. Every registry ACCEPTANCE item re-checked on this branch: canonical TypeScript runtime described and browser-capability separated from the M11 observatory; current evidence-backed M3 state taken from the ledger; legacy C# labeled a reference oracle in both the opening and the Building-and-testing section; Pages linked and described as it now renders; npm ci/typecheck/test/build and dotnet restore/build/test match package.json and the projects; no PARTIAL requirement claimed complete (REQ-VISUALIZATION-007 is the only row that was PARTIAL and this pull request earns it); no economic mechanic invented or changed. Verification on PR #499's head: npm run typecheck clean, npm test 655/655 passed (45 files; 7 net new), npm run build succeeded, scripts/tests 529 passed with 247 subtests; dotnet build Release 0 warnings 0 errors, dotnet test Release 45/45 passed (REQ-MIGRATION-003: canonical TypeScript evidence while the legacy build stays green). #504 (Issue #501, this pull request) repairs the next-state drift that PR #500 created when it backfilled this row's merge provenance: with that backfill all nine M3 registry requirements read IMPLEMENTED with a merge commit, release-tag.yml cut v0.3.0 - M3 on that evidence (published 2026-09-15T05:56:17Z), and the README's ""Not closed:"" block still asserted that Milestone 3 had not closed - contradicting both the release record and the ledger the README itself calls authoritative. The block now records M3 as closed and names the released tag while keeping the mechanical-release rule it explains, and the Current state section says M3 is complete instead of implying by contrast with ""Milestone 1 & 2: Complete."" that it is unfinished. Test that fails without the change: src/diagnostics/readme-conformance.test.ts gains an eighth case, ""never describes a milestone the ledger records closed as still open"", which derives milestone closure exactly the way scripts/release_tag.py derives it - membership from the MILESTONE column of the mirrored REQUIREMENTS_REGISTRY.csv, every member IMPLEMENTED with a non-empty MERGE_COMMIT, a blank MILESTONE gating nothing, and a milestone with no registry rows never vacuously closed - and reports a contradiction when a README block pairs a closed milestone with open-milestone language. Measured red then green on this branch: against the unrepaired README it fails with exactly one contradiction, 'M3 has landed in full (every registry requirement IMPLEMENTED with a merge commit) but README says ""not closed""', while the other seven cases pass; after the repair all eight pass. Reading both CSVs now goes through a quoted-field parser because MILESTONE sits after the registry's free-text STATEMENT and ANCHOR cells and cannot be recovered by splitting on commas. MERGE_COMMIT is left blank per AUTHOR_RUNBOOK.md section 7 - a row cannot know its own squash commit - and scripts/backfill_merge_commits.py fills it after merge; the previous value 7efd05a7c49f belongs to #499 and is recorded here rather than lost. Documentation and test only: no runtime, formula, schema, default, phase-order, milestone-membership or release-policy change, docs/spec/mirror/ is untouched, and no tag or release was created by this run. Verification on PR #504's head is recorded in that pull request's Checks table."
REQ-VISUALIZATION-008,IMPLEMENTED,447,489,838db1bc7ad4356c1603948678f302d2d2293d89,"Two concise public M3 reference articles, both reachable from the README's ""Understanding M3 local markets"" section: docs/reference/local-market-guide.md (price formation, clearing, shortage/surplus signals, deterministic ordering, market expectations) and docs/reference/market-settlement-and-taxes.md (settlement, seller-net versus buyer-gross, consumption-tax flow, reconciliation, telemetry). Contributing pull requests: #382 (merged 15caaa5bc79048b059273e1740eeae4ab8237cc4) added both articles and the README links; #405 (Issue #393, merged f3a0dd31c037529fdeb67d49f97a322e40d82871) corrected the realized observation to Phase-8 MAIN rather than the Phase-4 pre-production pass and defined shortageRate/surplusRate from effectiveDemandQuantity/offeredQuantity to match src/simulation/marketTelemetry.ts; #486 (Issue #446, merged bd61a157012c4af0d252789c80c42e48056b5194) corrected expectation causality and the expectation bootstrap boundary in local-market-guide.md; #489 (Issue #447, this pull request) repairs the last recorded conformance defect, in market-settlement-and-taxes.md. That article claimed ""the total quantity of each good across all actors is conserved"" after every tick and listed ""production value creation, consumption value destruction, or monetary policy"" together as coming money sources/sinks, which reads as production and consumption creating or destroying transaction money. Neither is canonical: validateZeroFlowReconciliation in src/simulation/ledger.ts checks that recorded MONEY and GOOD transfer flows net to zero per currencyId and goodId, while PHYSICAL_LOSS is a separate one-sided sink category explicitly exempt from that check (ledger.ts:183-185), and Gate M3 of the mirrored 06 - Handoff/11 document requires goods and transaction money to reconcile exactly after every settlement rather than across a whole tick. The Reconciliation section now separates transaction-level transfer conservation from whole-tick stock accounting, describes production, consumption, spoilage and physical loss only as typed physical sources and sinks, and confines money creation/destruction to authorized monetary and genesis operations; the Zero-Sum Principle closer is scoped to trades for the same reason. Settlement/tax examples, the inventory-endpoint rule, atomicity and telemetry text are unchanged. Documentation-only: no formula, default, state schema, phase order, runtime, settlement, telemetry computation or v1-scope change, and docs/spec/mirror/ is untouched. Promotion from PARTIAL to IMPLEMENTED: every registry ACCEPTANCE item was re-checked against the current text on this branch - two distinct articles committed, both linked from README lines 36-37; local-market-guide.md covers price/clearing/shortage-surplus and carries a ""Why Deterministic Ordering Matters"" section; market-settlement-and-taxes.md covers settlement, seller-net versus buyer-gross, consumption-tax flow, reconciliation and telemetry; both separate economic state from telemetry (the article's ""Authoritative Economic Transaction Records"" versus ""Telemetry Is Read-Only Observation"" sections) and introduce no alternate metric. No automated test can fail on prose conformance, so this row's evidence is the committed text plus green build/docs checks, not a regression test; the standing control is that a conformance defect is filed as an Issue, as #446 and #447 were. Verification on PR #489's head: TypeScript 612/612 tests passed (41 files), typecheck clean, build succeeded; C#/.NET 45/45 tests passed, build clean, 0 warnings (REQ-MIGRATION-003 maintained)."
REQ-VISUALIZATION-006,IMPLEMENTED,269,491,ab5f38785c380fa0625d1fbd9c8e5a21e4c5cbf2,"Consolidated M3 LocalMarket Pages experience (REQ-VISUALIZATION-006): PR #491 (Issue #269). src/diagnostics/m3Preview.ts generates docs/m3-preview.json from a deterministic ten-tick local-shortage golden run on the baseline-multistate-v1 scenario at seed 42 (Alpha Farmland market m:2, good good:food, settlement currency ALP, controller State Alpha), executing the real composed Phase-6 + Phase-8 handlers through executeTick() and carrying each tick forward across applyMarketSettlementTransition() then applyMarketStateTransition(). shortageRate and surplusRate are read off the canonical LocalMarketTelemetry that createPhase8Handler emits (REQ-MARKET-005); HANDOFF-REPAIR-009 forbids a second surplus metric and m3Preview.test.ts recomputes both published rates with computeShortageRate/computeSurplusRate to prove no parallel definition exists. Seller-net receipt, buyer-gross cost and collected consumption tax are summed from the realized MAIN-pass MarketAllocations settlement applies to authoritative stock. docs/index.html renders that artifact as the page's default view with the eight required headline metrics bound to one selected tick, price and traded-quantity trends as aligned small multiples (money and quantity never share an axis, per VIS-CHART-QA-001), a selected-tick market-balance visual, a settlement split, an exact-value table and explicit loading/empty/unavailable/error states; the M0-M2 cards and the legacy run.csv viewer move into a collapsed history disclosure. Tests that fail without the change: src/diagnostics/m3Preview.test.ts (11 tests) covering generator output, price bounds, the canonical rate sourcing, the settlement transfer identity buyerGrossCost = sellerNetReceipt + collected tax within moneyEpsilon, byte-identical regeneration from the same seed and non-mutation of the caller's WorldState; and src/diagnostics/m3-pages-render.test.ts (19 tests) driving the real docs/index.html in jsdom and in Chromium at 1280px and 360px, covering the default-view ordering and the collapsed disclosure, the metric labels and units against the artifact, selected-tick binding across every panel, table caption/scope/aria-current and chart aria-labels, narrow-layout overflow, all four lifecycle states through synthetic artifacts, a bypassed-render negative control, and the retained legacy viewer's scrubber label, table caption/row headers/column units and numeric needs-met value. Measured at 21bd55d370f0039192128de47072a3bc6bb34f7d: npm run typecheck clean, npm test 642/642 passed, npm run build succeeded, dotnet build Release 0 warnings, dotnet test Release 45/45 passed (REQ-MIGRATION-003: canonical TypeScript evidence while the legacy build stays green)."
REQ-CONFIG-006,IMPLEMENTED,527,546,cd12a1cd8bffd298ca237378687312da47c91355,"Composite completion: PR #528 (Issue #527, merge 8611040b4bd07b144ba5226fa2b2800e7bc340cf) declared and validated the full M4 ProductionConfig/LaborConfig surface and landed every baseline value then stated by Handoff/03, leaving fourteen behavior-affecting controls undefined rather than guessed while Q-001 was open. HANDOFF-REPAIR-M4-002 subsequently resolved Q-001 and made Handoff/03 sections 6-7 the sole owner of the missing defaults. PR #546 (Issue #533) lands those exact fourteen values in createDefaultSimulationConfig(): investmentReviewCadenceTicks=3, investmentUtilizationThreshold=0.75, minimumInvestmentMargin=0.05, investmentPropensity=0.35, maxInvestmentShareOfExcessCash=0.50, maxCapitalGrowthPerReview=0.25, lifecycleReviewCadenceTicks=3, mothballMarginThreshold=-0.10, mothballUtilizationThreshold=0.25, reactivateMarginThreshold=0.05, closingGraceReviews=4, maxLogWageStep=Math.log(1.05), unitVacancyResponse=0.02, maxTightnessSignal=2.0. src/config/m4ConfigDefaults.test.ts pins all fourteen canonical values, validates the resulting Production/Labor configs, and proves NumericConfig.quantityEpsilon remains the sole quantity-tolerance owner (no laborEpsilon). src/config/validation.test.ts removes only the obsolete Q-001 absence assertions; validator behavior coverage remains. docs/spec/OPEN_QUESTIONS.md records Q-001 ANSWERED with HANDOFF-REPAIR-M4-002 provenance. No production/labor behavior is claimed here; REQ-PRODUCTION-001..008 own it. Final judged PR #546 head `ec14fa1c2a8fa9bddfd75028fe908a84682d3051` had exact-head CI #1071 complete successfully with TypeScript, retained .NET, policy-guard and mergeability green; PR #546 then squash-merged as `cd12a1cd8bffd298ca237378687312da47c91355`."
REQ-CONFIG-007,IMPLEMENTED,549,550,cd6e685be439ac5ab2b5f3e5cb4661d9798f3385,"Composite completion: PR #532 declared and validated the M4 PopulationConfig and need-category configuration surface while Q-002 remained open; HANDOFF-REPAIR-M4-003 resolved Q-002; PR #550 lands the complete twenty-control canonical baseline and ownership rules without pulling M8 or population behavior forward. Implemented slice, PR #532: the twenty M4-subset controls section 33 of 06 - Handoff/06 - POPULATION_DEMOGRAPHY_CLANS_CONTRACTS.md names - liquidity floor (section 4), participation bounds and the health-participation and weak-opportunity clamps (section 8), the wage signal (section 9), the four welfare EMA alphas and the real-income scale (section 10) and the health-stock controls (section 11) - are declared on PopulationConfig in src/config/simulationConfig.ts; NeedCategoryDefinition and BASELINE_NEED_CATEGORY_IDS land on DefinitionPack in src/config/definitionPack.ts as an optional needCategories key, because Handoff/03 section 8 says need quantities and substitute groups belong to definitions and not to global config; validatePopulationConfig() and the need-category rules are in src/config/validation.ts, the latter called from validateDefinitionPack() because the goodId cross-reference needs the declared-goods set; and validateWorldGenesis() in src/simulation/worldState.ts runs validatePopulationConfig() beside the two REQ-CONFIG-006 calls, so an out-of-range control fails at genesis rather than at the first tick that reads it. Four controls carry a stated value: minHealthParticipationFactor 0.75 and maxHealthParticipationFactor 1.02 from section 8 of Handoff/06 itself (""Recommended healthParticipationFactor range [0.75,1.02]""), and wageSignalAdjustmentSpeed 0.20 and prosperityAlpha 0.15 mapped from section 8 of Handoff/03 wageSignalAlpha and prosperityEmaAlpha. Both mappings are forced rather than chosen - the section 9 update wageSignal x exp(speed x ln(target/wageSignal)) is algebraically a geometric EMA with that smoothing factor, and neither document declares a competing wage-signal or prosperity smoothing control - and both are recorded as inferences in the pull request body and the Decision comment on Issue #531. Three further divergences were refused on the Q-001 maxLogWageStep precedent, because mapping them would invent a semantic: liquidityFloorShare versus precautionaryCashFloorMonths 0.25 (a share versus a number of months, and section 4's floor needs both of its own parameters), per-category priceSensitivity_c versus the single global needSubstitutionElasticity 0.60 (section 5 requires ESSENTIAL_FOOD and COMFORT to differ, which one global contradicts), and healthEmaAlpha 0.20, which has no counterpart at all. Deliberately not declared, each with the sentence that places it elsewhere: workerEpsilon (section 9), because workers are measured in worker-equivalents, a quantity, and NumericConfig.quantityEpsilon owns that tolerance - the HANDOFF-REPAIR-010 precedent #528 applied to laborEpsilon; and the section 10 P_raw weights, because section 33 does not list them among what PopulationConfig centralizes, they must sum to 1.0, and section 33's ""Scenario files may override values but may not introduce new bespoke formulas without schema version change"" is what a scenario-tunable weight vector would defeat. Tests that fail without the change, in src/config/validation.test.ts: the four stated defaults pinned against their spec sentence; the population block deterministic across calls and accepted by its own validator; one absence test per unvalued control, so filling one in without answering Q-002 fails the build; twenty absence tests covering the deferred M8 demography/migration/mobility controls, so pulling M8 forward fails the build; a test asserting the full M4-subset field list is declared; non-finite, out-of-range, inverted-participation-bound and inverted health/opportunity-clamp rejection, plus entry-by-entry validation of baseParticipationByStratum; need categories validated as a set (exactly the four baseline ids accepted, an unknown id rejected, a missing baseline id rejected, a key/id mismatch rejected, an empty substitutionGoods list rejected because section 5 normalizes share_g = weight_g / sum(weight) and an empty list makes every share 0/0, a repeated goodId rejected because it would double-count its own weight in that same normalization, a non-positive basePreference or qualityFactor rejected, and a goodId the pack does not declare rejected - the REQ-CONFIG-005 negative control from #512 and #516 applied to the new reference); a negative control asserting no PopulationConfig key duplicates a LaborConfig, MarketConfig, ProductionConfig or NumericConfig key, checked over all twenty declared controls and, at the type level, over the declared sibling surfaces too, because both sides leave controls undefaulted and Object.keys() of the runtime defaults saw only four of the twenty; assertNoBehavioralOverrides still refusing a scenario carrying population; the seven remaining sibling placeholders still empty; and six existing numeric/markets/production/labor values pinned unchanged. Ten further tests in the new src/simulation/genesisPopulationConfig.test.ts run the enforcement end to end through buildInitialWorld() on the baseline scenario: the canonical defaults accepted, a non-finite control, an out-of-range control, an inverted participation clamp and an out-of-range per-stratum rate each rejected before construction, a pack declaring no needCategories accepted (the baseline pack declares none, and household demand is REQ-POPULATION-001's to run), and a need category naming an undeclared good rejected; and, after researcher QA on head d6c99db, three tests proving a valid non-empty four-category pack survives buildInitialWorld() unchanged into world.definitionRegistry.needCategories, field for field, with absence preserved as absence. The negative control was run: with the validatePopulationConfig() call commented out of validateWorldGenesis() and the tests in place, exactly the four config-bound regressions fail and the other three pass (4 failed | 3 passed of 7); restoring the call returns 7/7. The DefinitionPack -> DefinitionRegistry -> WorldState boundary is closed in the same pull request: needCategories was validated at genesis and then discarded, because src/domain/definitionRegistry.ts projected only goods/recipes/eventDefinitions/metricDefinitions and DefinitionPack is not reachable from WorldState, so REQ-POPULATION-001..003 would have had no canonical source for the categories this row declares; needCategories is now in the DefinitionRegistry Pick and in buildDefinitionRegistry(), with a test in src/domain/definitionRegistry.test.ts that derives the expected projection from the pack rather than naming fields by hand, so the next definitions field added and forgotten fails instead of disappearing. Negative control run: reverting the projection fails exactly those four tests and no others. At the branch head the TypeScript suite passed 840/840 (50 files, up from 827/49 on master), typecheck and build passed, and legacy .NET passed 45/45 (REQ-MIGRATION-003 maintained). Completion slice, PR #550: src/config/m4PopulationDefaults.ts materializes the complete twenty-control HANDOFF-REPAIR-M4-003 baseline; createDefaultSimulationConfig().population uses createDefaultPopulationConfig(); focused regressions pin the exact values including Math.log(1.05), validator acceptance, per-call reference isolation, stale-alias exclusion and M8 exclusion; src/config/validation.test.ts replaces the obsolete undefined-default assertions with materialization/ownership checks; docs/spec/OPEN_QUESTIONS.md records Q-002 ANSWERED; the existing needCategories DefinitionPack -> DefinitionRegistry -> WorldState projection remains intact. Exact-head CI run 35280031062 on 68a911a8e558e9e0a829da61191c2a21d30e4955 passed TypeScript typecheck/tests/build, retained .NET build-and-test, policy-guard (including handoff, generated-status and ledger-honesty checks) and mergeability. PR #550 then merged as cd6e685be439ac5ab2b5f3e5cb4661d9798f3385; M4 population behavior remains owned by REQ-POPULATION-001..003 and no such behavior is claimed here."
REQ-PRODUCTION-001,IMPLEMENTED,558,559,96ed4198e3f3220916e9ce78455befe37ff971f3,"PR #559 implements the M4 persistent ProductionUnit state boundary: live installedCapital is the sole mutable capacity stock; ProductionSignalState and lastLifecycleReviewTick are materialized at genesis; INPUT/OUTPUT/INVESTMENT inventories remain distinct physical maps; deriveNameplateCapacity derives batches per tick strictly as installedCapital × RecipeDefinition.batchesPerCapitalUnit without a serialized capacity authority; validateProductionUnitPersistentState rejects non-finite or negative capital/inventory, inventory aliasing, out-of-range or non-finite signals, invalid counters and review ticks; genesis reconciliation reads live installedCapital and its capital-removal negative control mutates the live authority. Focused proof: src/simulation/productionUnitState.test.ts (8 tests) plus the updated genesisReconciliation capital-removal negative control. Exact-head CI run 35306469114 on b2dabe251952dd6dd79b15e4cdc384398b3f8155 passed TypeScript typecheck/tests/build, retained .NET build/test, policy-guard and mergeability. PR #559 then squash-merged as 96ed4198e3f3220916e9ce78455befe37ff971f3; no Phase-2 planning, production execution, investment execution, lifecycle transition behavior, M5+, or mirror change is claimed."
REQ-PRODUCTION-002,IMPLEMENTED,570,571,219ae9a4e9422071af984118b18114123fca466e,"PR #567 established the deterministic ACTIVE-unit Phase-2 production/labor/INPUT planner and canonical INPUT budget commitments. PR #571 completes the repaired REQ-PRODUCTION-002 boundary from HANDOFF-REPAIR-M4-004 / Handoff/05 sections 19-20: ordinary investment review runs only on tick > 0 cadence multiples; demand, margin and sales pressure use the fixed equal one-third weights; workingCapitalTarget protects mandatoryKnownCash + grossWageCashEnvelope + desiredInputCost + operatingLiquidityBuffer before investment; investmentBudget is bounded from excess opening home cash; desired capital growth is capped by maxCapitalGrowthPerReview; existing INVESTMENT inventory is subtracted; material desired purchases require finite positive prior-close gross INVESTMENT prices; goods and IDs are stable-good ordered; canonical BUY/INVESTMENT intents keep sourcePlanId=ProductionPlan.planId, inventoryBucket=INVESTMENT and commit maxSpend through a distinct `${planId}:INVESTMENT` budget-ledger envelope. Focused regressions in src/simulation/productionPlanning.test.ts prove due-cadence pressure/budget/intents, genesis/off-cadence suppression, price-evidence fail-fast, distinct INPUT versus INVESTMENT commitments with duplicate-overcommit rejection, insertion-order determinism, same-tick transaction/market context non-financing, and no planning-time installedCapital or investmentInventory mutation. Phase-3 labor allocation, Phase-5 execution/output sale, Phase-12 capital formation/depreciation, lifecycle transitions, MOTHBALLED reactivation eligibility and M5+ remain owned by their separate requirements and are not claimed here."
REQ-POPULATION-002,IMPLEMENTED,575,576,d7a8328acdec451dd34844bd06658e5e468ad329,"PR #576 implements the complete M4 Population-owned Phase-2 LaborSupplyPlan boundary from HANDOFF-REPAIR-M4-005 / Handoff/06 section 8: only positive-population WORKING cohorts emit normal supply; participation uses the Population-owned stratum baseline multiplied by the exact linear health and prior-close opportunity factors with neutral M4 workingEligibility/lawParticipationFactor and configured min/max clamps; available worker-equivalents are bounded to cohort population; IDs and enumeration are stable by persistent cohortId; plans are ephemeral TickContext state with no RNG, WorldState mutation or employer linkage. Focused regressions in src/simulation/laborSupplyPlanning.test.ts prove factor endpoints/clamping, CHILD/ELDER and zero-population exclusion, tiny-positive supply, invalid/non-finite evidence rejection, missing-stratum rejection, insertion-order equivalence and no cohort-state mutation. Substantive code head fe2782e77e208c9b002516aaa3e12aa658faf580 passed CI run 35411625919 with TypeScript typecheck/tests/build, retained .NET build/test and policy-guard; final evidence-only head reruns required gates before SLOPSTER judgement. Phase-3 allocation/wage settlement, household consumption, persistent employer stock, Phase-13 demography/migration, M6 institutions and M5+ remain separate requirements."
REQ-PRODUCTION-003,IMPLEMENTED,581,582,ec958ed3fb01fb0524ccad883b62e4c157399608,"Composite completion: merged PR #579 implements Handoff/05 section 13 deterministic Phase-3 region×labor-category allocation over canonical LaborSupplyPlan/LaborDemandPlan evidence; PR #582 closes the remaining Handoff/05 section 14 sticky N+1 wage-offer boundary. ProductionUnitState now owns live wageOffer as canonical persistent state, initialized from the opening seed or canonical LaborConfig startingReferenceWage, validated as finite/non-negative, and read by Phase-2 planning instead of immutable scenario seed data. Phase 15 derives regional tightness from requested versus available labor using NumericConfig.quantityEpsilon, applies configured bounded regional wage growth plus bounded per-unit vacancy pressure to ACTIVE units, floors the exponential next offer at explicit next-tick effective minimum-wage evidence, emits deterministic tick-scoped WageOfferUpdate records, and persists them only through an explicit between-tick WorldState transition. src/simulation/wageOfferUpdate.test.ts proves PCL-T9 tight-market increase/slack-market decrease, max-step and vacancy clamps, minimum-wage flooring, ACTIVE/zero-demand semantics, insertion-order invariance, malformed/duplicate/incomplete evidence fail-fast behavior and N+1 persistence without in-tick mutation; src/simulation/productionPlanning.test.ts proves Phase-2 reads the live wageOffer rather than seed.wageOffer. Phase-5 payroll/wage settlement remains REQ-PRODUCTION-004; no persistent employer stock or M5+ behavior is claimed."
REQ-PRODUCTION-004,IMPLEMENTED,584,585,401f0480146d4f1c70959b02cfe42cf4cacb0846,"PR #585 implements Handoff/05 section 15 atomic Phase-5 wage settlement over canonical Phase-3 LaborAllocation evidence. Whole-tick preflight validates current-tick allocation provenance, ACTIVE employers, exact worker-equivalent times wage gross obligations, per-unit Phase-3 grossPayrollCap and available Region settlement-currency cash before any stock transition. Controlled Regions use an explicit deterministic read-only M4 WageTaxPolicyProvider; uncontrolled Regions assess and collect zero State wage tax. Each accepted bundle conserves employer gross debit as cohort net wage plus State collected tax, leaves assessed-but-uncollected tax with the cohort, emits stable linked WAGE_PAYMENT and positive WAGE_TAX_WITHHELD transactions, and persists wallets only through the shared canonical actor-wallet transition seam. getPostWageSpendableBalance exposes the same accepted Phase-5 deltas to later current-tick affordability without mutating WorldState. Focused regressions in src/simulation/wageSettlement.test.ts prove PCL-I9/PCL-I10/PCL-T6 conservation, partial/zero withholding, uncontrolled jurisdiction, cap/cash refusal, malformed/stale/duplicate/cross-provenance rejection, insertion-order determinism, input-world immutability and current-tick spendable-balance visibility. Phase-10 duplicate wage taxation, production/output execution and mutable M6 fiscal/transfer/debt/review behavior are not introduced."
REQ-PRODUCTION-005,IMPLEMENTED,587,588,7c3509455869e721703be3785a2b9acada37d5da,"PR #588 implements Handoff/05 sections 16-17 and 26 deterministic Phase-5 production/extraction: stable ProductionUnit ordering; realized batches are bounded by the current ProductionPlan, exact live INPUT stock, Phase-3 allocated labor, effective capacity and finite regional resource deposits; shared deposits are reserved/depleted exactly once; exact recipe inputs decline and exact output enters ProductionUnit OUTPUT before the canonical reserve-based SELL intent is built. RegionState now owns the persistent live finite-resource balance, initialized once at genesis from immutable RegionSeed deposits and thereafter carried only through explicit immutable WorldState transitions, so depletion cannot reset to scenario seed. applyProductionExecutionTransition validates unit/region/recipe provenance and exact physical deltas and rejects input/resource overdraw, missing recipe consumption and phantom output. Focused regressions in src/simulation/productionExecution.test.ts prove independent input/labor/capital/resource bottlenecks, finite depletion and zero-after-depletion, shared-resource no-double-spend, exact once-only stock transitions, output-first sale intent, non-ACTIVE suppression, forged-delta refusal, malformed/stale/cross-group evidence rejection, insertion-order determinism and input-world immutability. No random production multiplier, labor refund, market-clearing rewrite, investment/capital formation, lifecycle behavior, M5+ behavior or mirror edit is claimed."
REQ-POPULATION-001,IMPLEMENTED,591,592,2a19a1b7fb672d72223078fc70cff30d5f8fa663,"PR #592 implements Handoff/06 sections 4-5 deterministic M4 Phase-2 household consumption planning over the canonical four need categories. Positive-population cohorts reserve the canonical liquidity floor from opening settlement-currency cash; M4 expectedCurrentTickIncome remains zero because no already-committed transfer entitlement surface exists and unsettled Phase-5 wages are not spendable in Phase 2. ESSENTIAL_FOOD is funded before BASIC_GOODS/SERVICES configured minima/targets and COMFORT, while emitted MarketIntents deliberately carry no clearing priority. Substitution uses stable log-space normalization of basePreference × qualityFactor / max(expected prior-close gross buyer price, moneyEpsilon)^priceSensitivity; uncontrolled Regions use zero State consumption tax, while controlled Regions require the same explicit read-only TaxPolicyProvider semantics as Phase 8 so gross price includes collected consumption tax before substitution and quantity planning. It then emits canonical Cohort BUY/CONSUMPTION intents with stable IDs, desiredQuantity, maxSpend and sourcePlanId. Budget commitments use canonical actorRefKey ownership so cohorts with identical envelopes cannot collide. Focused regressions in src/simulation/householdConsumptionPlanning.test.ts prove liquidity floors, essential budget priority without market priority, finite low-price normalization, malformed price/need rejection, same-tick wage exclusion, cohort commitment isolation, insertion-order equivalence, zero-population exclusion and planning-time WorldState immutability. Phase-8 affordability/settlement and Phase-9 realized consumption/spoilage remain separate owners; no second shopping loop, household credit, M5+ behavior or mirror edit is introduced."
REQ-POPULATION-003,IMPLEMENTED,596,597,652b8639a0596493f96d25ed3d6ce7b7e2d091b5,"PR #597 implements Handoff/06 Phase-9 household realization and economic evidence: positive-population cohorts consume the single canonical householdInventory against stable priority-ordered need categories, use candidate qualityFactor as the per-unit useful-equivalent conversion, compute bounded category coverage and canonical essentialCoverage, and share one working inventory so overlapping categories cannot double-consume physical stock. Realized Phase-8 MAIN purchases are projected only during immutable-tick planning; applyHouseholdConsumptionTransition refuses persistence unless canonical market settlement has already produced that exact post-market stock, so Phase 9 never becomes a second settlement path. Excess carryover above required useful consumption times inventoryCarryoverTicks destroys only eligible perishable stock and emits explicit HOUSEHOLD_SPOILAGE transaction plus PHYSICAL_LOSS(spoilage) evidence; consumption likewise emits attributed one-sided physical loss while durable excess is retained. Economic evidence reuses LaborSupplyPlan availability, Phase-3 LaborAllocation employment/gross obligations, Phase-5 WageSettlement and exact WAGE_PAYMENT transaction net receipts, validating gross = net + collected withholding without rematching labor or recomputing tax/transfers. Focused regressions in src/simulation/householdConsumptionExecution.test.ts prove shortage/no-negative inventory, canonical essential coverage, perishable spoilage and durable retention, overlapping-good single use, Phase-8 settlement precondition, employment/wage reconciliation and malformed wage rejection, insertion-order equivalence, TickContext-only handler behavior and input-world immutability. Phase-13 demography/migration, household resale/replanning, M5+ behavior and mirror edits remain out of scope."
REQ-PRODUCTION-006,IMPLEMENTED,601,602,950e8b1f98985fe9af6eda97bc9795efdbc8984c,"PR #602 implements Handoff/05 Phase-12 real-goods capital formation and depreciation. planCapitalFormationPhase12 reads only canonical ProductionUnit investmentInventory, installedCapital and immutable recipe coefficients, computes possible capital as the stable-good minimum inventory/coefficient ratio, consumes complete investment-good bundles exactly once, increases the sole installedCapital authority once, then applies recipe depreciation exactly once to post-formation capital with no money transaction or cash recipient. applyCapitalFormationTransition requires exactly one current execution per ProductionUnit, recomputes the deterministic evidence against current authoritative stock to reject stale/tampered replay, preserves INPUT/OUTPUT inventories, wallets, signals and unrelated world state, and returns a new WorldState. The Phase-12 handler records tick-scoped evidence only, so its result cannot affect already-completed same-tick Phase-5 capacity and becomes usable only through the explicit state transition. Focused regressions in src/simulation/capitalFormation.test.ts prove exact multi-good conversion, partial-bundle accumulation, post-formation depreciation, no-cash behavior, zero-investment-recipe depreciation, stale/tampered and missing-unit refusal, insertion-order determinism, handler immutability/next-state capacity, and non-finite/invalid coefficient rejection. Phase-14 lifecycle, integrated M4 orchestration and M5+ remain separate requirements."
REQ-PRODUCTION-008,IMPLEMENTED,650,651,170dc4cdb3ef0e2f0a42a7439714f5ac464fd4ea,"PR #651 composes the canonical one-Region M4 closed-economy tick through the existing 0..15 orchestrator using immutable WorldState threading: Phase 2 production/labor/household plans, Phase 3 labor allocation, Phase 4 PRE_PRODUCTION procurement and settlement, Phase 5 wage settlement plus production/output offers, canonical M3 Phase 6/8 price formation and MAIN clearing, Phase 9 household consumption, Phase 12 capital formation, Phase 14 lifecycle review and Phase 15 wage-signal persistence. Phase 7 remains inert, so M5 trade/shipments/FX cannot feed same-tick Phase 5. Residual Phase-4 production demand is reduced before MAIN, and all persisted transitions are explicit. src/simulation/m4ClosedEconomyOrchestrator.test.ts proves exact 0..15 order, input-world immutability, insertion-order determinism, positive Phase-4 procurement into an initially empty INPUT bucket that is consumed by Phase-5 production, Phase-5 output becoming a positive Phase-8 MAIN sale, positive wage recipients participating in the same Phase-8 market, and no Phase-7 transaction. The integration also repairs lifecycle authority leaks found while composing the tick: labor allocation, wage settlement and wage-offer update now consult the live ProductionUnit status rather than immutable seed status, with focused seed/live divergence regressions. No M5+ behavior or mirror edit is introduced."
REQ-PRODUCTION-007,IMPLEMENTED,635,636,8f44c3ead86ca8b9ca3623a9911132492c22851e,"PR #636 implements the canonical M4 ProductionUnit lifecycle/startup boundary: one live status authority initialized from immutable seed status; PLANNED startup INVESTMENT intents from opening unit cash; explicit zero-sum owner funding in the Region settlement currency; deterministic cadence-bound Phase-14 reviews for ACTIVE mothballing, MOTHBALLED reactivation/closing and CLOSING retirement; exact next-tick lifecycle activation through pending transitions; fail-closed evidence re-derivation and safe retirement; and live-status gating in Phase-2 planning, Phase-5 execution and Phase-12 capital formation. Focused regressions in src/simulation/productionUnitLifecycle.test.ts and src/simulation/productionStartupPlanning.test.ts cover startup readiness/N+1 activation, same-tick causal isolation, funding conservation, configured consecutive reviews/reset/reactivation/closing, residual-stock retirement refusal/safe retirement, seed/live-status divergence, insertion-order determinism and tampered lifecycle evidence. Merge commit intentionally blank until integration."
REQ-ACCEPTANCE-005,IMPLEMENTED,657,661,cd5e77727b1696dd3934cff378135ca3210a53cf,"PR #661 repairs the permanent M4 golden so household MAIN settlement is proven against authoritative WorldState mutation rather than allocation-only evidence. src/simulation/acceptance-005-m4-golden-gate.test.ts observes accepted post-Phase-5 and pre/post-Phase-8 state boundaries, reconciles every MAIN goods and money leg against canonical actor inventories/wallets including the seller side, proves household gross debit against the authoritative post-wage cash available to Phase 8, and includes a negative control that neutralizes the post-Phase-8 stock state while preserving the same allocations and must fail mechanically. The existing 240-tick phase/reconciliation, production/extraction, payroll, capital, lifecycle-hash, finite-stock and same-input determinism checks remain load-bearing."
REQ-VISUALIZATION-009,IMPLEMENTED,658,659,a55b4da3fb633d07016a504bc028cc99ab5b4ec3,"PR #659 publishes the deterministic one-region M4 Pages preview from the authoritative executeM4ClosedEconomyTick path. src/diagnostics/m4Preview.test.ts proves byte-deterministic projection, non-vacuous production/wage/employment/needs/inventory/capital facts and caller WorldState/RNG isolation; src/diagnostics/m4-pages-render.test.ts exercises Chromium at desktop and 360px narrow viewports plus empty, unavailable, invalid-JSON and malformed-shape handling. docs/m4-preview.json is the checked-in deterministic artifact; docs/index.html, docs/m4.css and docs/m4.js make M4 the first visible Pages story while retaining earlier milestones. Exact-head TypeScript install/typecheck/tests/build, retained .NET restore/build/tests, policy-guard and mergeability were green before SLOPSTER judgement."