Snapshot date: 2026-08-26
Canonical base: main@a90b017ab29171e00174f2a56c719c32241a63f1
The project is tracked by subsystem/layer gates rather than one linear phase number.
C++20/CMake, Windows+Ubuntu CI, evidence/artifact identity, GDSpaces identity/source/provenance, Binary Inspector, EXE evidence, WorkingCopy, guarded output infrastructure and guarded canonical-EXE window acquisition are maintained foundations.
Canonical execution plan: L1 roadmap.
Mandatory acceptance sequence:
direct-retail member provenance
-> representation classification
-> real bounded edit
-> bottom-up PAC/PNST rebuild
-> next-volume NBZ publication/reopen
-> exact authored rematerialization
-> original-game consumption
-> rollback
-> final L1 acceptance audit
Current main already contains the representative internal product path. Remaining completion gates are real-retail/original-process evidence, not another parser rewrite.
Merged #228 canonically replaced old generic fan-in/completion shorthand with the narrower materialization completion ordering / dependency bridge. Merged #230 further proves that normal 0x1401B8DC0 receives only one u32 registry-relative context and does not receive transport status/error/byte-count/outstanding-work metadata.
The follow-up pass therefore asks a small terminal-state question rather than searching for a generic child counter:
0x1402EF4D0 materialization job/submission
-> lower whole-file/FileSlot transport
-> terminal status / job-retirement condition
-> queued 0x1401B8DC0(record-context)
-> state2
FIFO insertion order alone is not enough unless the earlier materialization job has completion-aware persistence/retirement semantics.
Current raw-pass priority:
0x1402EF4D0 queued job identity/type
-> 0x1402EF790 materialization-job persistence/re-poll/retirement
-> 0x1400333E0 historical status/poll anchor
-> 0x140033390 historical terminal cleanup/release anchor
-> 0x1400335A0 transport status/error writes
-> 0x1402EF460 queued-completion suppression/rollback
-> .lst child/recursive failure ordering after the direct-resource mechanism is closed
0x1400333E0 and 0x140033390 remain reacquisition hypotheses until fresh canonical bytes confirm their exact historical roles. No generic fan-in counter is claimed.
Type-0 post-0x0C static physical-provider behavior is no longer the primary gap. Current closure depends on real-retail collision evidence, protected-process RVA mapping and trusted selected-provider identity receipts.
L2 may support the L1 vertical proof but does not substitute for L1 materialization acceptance.
Static authority is strong for the central LoadedResource state spine, scheduler callback ABI, cancellation/quiescence/release distinctions and representative typed post-load families.
The materialization completion bridge is cross-layer evidence: FileSlot byte-read mechanics may support L1, while FileSlot/AsyncIO request ownership/scheduling/callback lifecycle and LoadedResource states remain L3.
Open L3 work is now residual static ownership/value-flow breadth plus trusted original-process lifecycle receipts.
Stage Ops owns product-side stage assembly/orchestration over GDSpaces outputs. Stage Semantic Graph represents that state. ModViz consumes it. None may create a private resource resolver or archive materializer.
Major game-backed Stage Ops expansion should not displace GDS real acceptance or evidence-driven closure.
EXE Editor should expose one canonical recovered-source tree linked to exact binary ranges, ABI/ownership/lifetime evidence and validation receipts. Progressive recompilation remains downstream of bounded behavioral comparison.
L1 real-retail/game-backed acceptance
-> narrow L2 evidence closure
-> representative L3 dynamic lifecycle validation
-> Stage Ops game-backed assembly
-> semantic/editor verticals
-> bounded recovered-subsystem equivalence
-> progressive recompilation
-> working rebuilt executable milestones
This ordering is dependency priority, not a ban on parallel evidence work.