Repository navigation
REQ-CONFIG-003: Complete M1 world-genesis and baseline scenario #138
Copy link
Copy link
Closed as not planned
Labels
area:simulation-coreTick loop, ordering, determinism, configurationTick loop, ordering, determinism, configurationpriority:normalDefault planned priorityDefault planned prioritytype:featureNew simulation capability or observable behaviorNew simulation capability or observable behavior
Description
Goal
Complete REQ-CONFIG-003 by implementing the remaining baseline definition pack and scenario content needed for M1 milestone gate.
Evidence
- Specification: docs/spec/mirror/06 - Handoff/03 — CANONICAL_CONFIG_AND_WORLD_GENERATION.md, sections 16A–20
- Current status: REQ-CONFIG-003 is PARTIAL (only seed/GoodDefinition self-contained types implemented)
- Remaining work identified in implementation_status.csv evidence
Scope
- Integrate RecipeDefinition schema from PRODUCTION contract (section 16A, already documented in spec)
- Implement buildInitialWorld() function (section 19: exact 17-step initialization order)
- Implement WorldGenesisLedger schema and opening-stock reconciliation (section 20)
- Author baseline-multistate-v1 scenario (section 17) with required topology:
- 24 regions in sparse connected graph
- 4 initial states controlling most regions
- 4 currencies and 4 monetary authorities
- 8 clans with cross-border patterns
- 400–600 starting cohorts
- 150–300 production units spanning baseline recipes
- Implement M1 initialization invariants and required tests (sections 24–25)
Non-goals
- Do not implement later-milestone behaviors (fiscal policy, clan relations, bonds, events, metrics)
- Do not implement production, labor, investment, depreciation, or FX dynamics—only schema/validation
- Do not author multiple scenarios; baseline-multistate-v1 only
Acceptance criteria
- RecipeDefinition schema is accessible and validated in config layer
- buildInitialWorld() executes all 17 steps in exact documented order
- WorldGenesisLedger records and reconciles all opening stocks within SimulationConfig tolerances
- baseline-multistate-v1 scenario is checked in and loads without error
- All M1 initialization invariants pass (24 required tests per section 24)
- TypeScript: npm ci && npm run typecheck && npm test && npm run build all pass
- C#/.NET: dotnet build/test remain green (migration requirement REQ-MIGRATION-003)
- Implementation status updated: REQ-CONFIG-003 moves from PARTIAL to IMPLEMENTED
Verification
npm ci && npm run typecheck && npm test && npm run build
dotnet restore && dotnet build --configuration Release --no-restore
dotnet test --configuration Release --no-buildBlocking gate
None known. REQ-CONFIG-001, REQ-CONFIG-002, REQ-CORE-003 are all IMPLEMENTED.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
area:simulation-coreTick loop, ordering, determinism, configurationTick loop, ordering, determinism, configurationpriority:normalDefault planned priorityDefault planned prioritytype:featureNew simulation capability or observable behaviorNew simulation capability or observable behavior
Activity
drevendev commentedon Sep 5, 2026
REVIEW/QA correction for the bounded REQ-CONFIG-003 work item.
The upstream task now exists, which resolves the queue-liveness gap reported by the researcher. However, this Issue currently crosses the permanent requirement boundary.
Canonical registry ownership is:
baseline-multistate-v1scenario, with the M1RecipeDefinition/ FX-pool initialization boundary and deterministic variation.WorldGenesisLedger+ opening-stock reconciliation; it explicitly DEPENDS_ON REQ-CONFIG-003.Therefore #138 must not claim or implement CONFIG-004 acceptance as part of CONFIG-003. In particular, remove
WorldGenesisLedgerimplementation/reconciliation from #138 scope and acceptance, and do not require CONFIG-003 to prove the CONFIG-004 opening-stock invariant. Keep #138 bounded to completing the baseline definition/scenario material and the CONFIG-003-owned initialization data needed to construct it.buildInitialWorld()may only be included here to the extent required to instantiate/validate the CONFIG-003 scenario without prematurely claiming CONFIG-004; the ledger/reconciliation behavior belongs to the downstream CONFIG-004 task after CONFIG-003 is IMPLEMENTED.Also do not derive remaining work from the stale prose in
implementation_status.csv: that ledger currently omits merged PR #91 and still falsely listsStateSeed,MonetaryAuthoritySeed, andClanSeedas open. Use the current mirrored Handoff contract for specification scope and the ledger only for implementation evidence.No economic mechanism changes are requested; this is requirement-boundary and milestone-order conformance only.
drevendev commentedon Sep 5, 2026
AUTHOR Claim
Role: AUTHOR
Issue: #138 (REQ-CONFIG-003)
Branch: claude/issue-138-config-003-complete
Scope: Complete REQ-CONFIG-003 by implementing RecipeDefinition schema, buildInitialWorld() function with 17-step initialization order, WorldGenesisLedger with opening-stock reconciliation, baseline-multistate-v1 scenario, and 24 required M1 initialization invariant tests.
Known blockers: None identified at claim time. Work will follow spec sections 16A–20 of CANONICAL_CONFIG_AND_WORLD_GENERATION.md exactly.
drevendev commentedon Sep 5, 2026
AUTHOR Scope Assessment — BLOCKED
Gate: Issue #138 scope exceeds single AUTHOR run capacity.
Analysis: The acceptance criteria require:
Estimated effort: 20–30 hours of focused implementation work.
Recommendation: Split Issue #138 into smaller, sequentially-dependent issues:
Each sub-issue should be marked as status:ready and carry REQ-CONFIG-003 as its requirement ID, with sequential dependencies linking them so later Issues unblock after earlier PRs merge.
Per AUTHOR_RUNBOOK section 8: A run that cannot proceed says so, records the exact gate and reason, and stops.
drevendev commentedon Sep 5, 2026
CONSISTENCY/SIMPLICITY QA follow-up.
The BLOCKED assessment is directionally correct that Issue #138 is too large for one bounded AUTHOR run, but its proposed split must not invent requirement identifiers such as
REQ-CONFIG-003a..003e. Requirement IDs are permanent and come only from the Drive registry. Existing compositeREQ-CONFIG-003remains one permanent ID and uses PARTIAL evidence across multiple bounded implementation Issues until the full row is satisfied.Smallest compliant split: create several ordinary implementation Issues, each all referencing the same permanent
REQ-CONFIG-003, for independently bounded slices such as RecipeDefinition/FxPoolSeed initialization data, baseline scenario content, buildInitialWorld construction needed for that scenario, and CONFIG-003 proving tests. Sequence them with Issue dependencies if useful. Do not create pseudo-REQ IDs.Also remove the proposed
WorldGenesisLedger/opening-stock reconciliationsub-issue from the CONFIG-003 split entirely. That behavior is already owned by permanentREQ-CONFIG-004, which depends on CONFIG-003. Issue #135 remains the downstream task for that requirement once CONFIG-003 is actually IMPLEMENTED.No spec/economic change is requested; this is permanent-ID, task-granularity and milestone-boundary conformance.
REQ-CORE-005: Change status to PARTIAL per formal review feedback
drevendev commentedon Sep 6, 2026
OPERATOR decision: closed as superseded.
This umbrella carried the whole of REQ-CONFIG-003 and was split into bounded Issues (#154, #157, #167) that have merged; the ledger row was promoted by #173. The QA debt found after those merges now has its own work items: #200 (REQ-CONFIG-003: LocalMarket persistent ID, RecipeDefinition bounds validation) and #201 (REQ-CONFIG-004: reconciliation against actual tick-0 stocks). Both are
status:ready,priority:high, in the M1 queue. Nothing remains here for an AUTHOR run to take.