1.0 Requirements and Roadmap

MKMSZR 1.0 requirements and roadmap

Release gate refinement (2026-10-09): accelerated Inventory music and audio clipping remain a hard 1.0 blocker, but the narrow upstream timing hypothesis is now testable. Independent captured Trace (6)/(7) runs exhibit ~40 seconds of consecutive native 368-frame output with AI_LEN decreasing 1,344→1,280 before FIFO rejections. The pinned RMG core's AI DMA duration uses an early integer truncation to 551 Count/byte instead of ~551.838, causing a measured-clock guest-versus-SDL rate difference that quantitatively explains host queue drift and is a plausible contributor to guest FIFO phase lock. This is not a validated production fix or complete attribution of historical patch-corruption incidents. Draft PR #161 is an opt-in emulator-only rational-duration A/B diagnostic based on draft host observers #160/#157. The release gate requires an actual comparative runtime outcome and confirmation that gameplay/audio pacing remain correct, plus independent evaluation of whether a portable MKMSZR-side change is necessary. Retain all accepted features, the rejected enqueue retry prohibition and ROM safety requirements. See audio investigation.\n\nRelease gate update (2026-10-08): production rich Inventory accelerated music remains a blocker. Repeated rejected PCM is now measured, but the upstream Inventory/scheduler/consumer trigger and full audible accounting remain Pending. Require generation/deadline chronology and a matched rendering control before a permanent correction or promotion of draft PR #156. Preserve rich presentation/gameplay; AI enqueue retry is explicitly rejected for this investigation. See upstream investigation.

Scope: This page is the canonical owner for MKMSZR 1.0 required behavior, acceptance criteria, release blockers/non-blockers, dependency order, and final release-validation gates. Technical mechanism and proof chronology remain on the owning domain pages.

Release definition

MKMSZR 1.0 is not complete with the current stage-local pickup shuffle alone. The release boundary requires a deterministic global run model that can place ordinary randomized items across the eight main stages, reject unwinnable layouts deterministically, present enough run state to the player, preserve the required run resources and invariants across lifecycle boundaries, and pass representative full-seed runtime validation.

Current implementation maturity is not itself a requirement. A feature may already be Production/Production beta while still needing a final 1.0 acceptance gate, and a runtime proof does not automatically make a proof-only mechanism part of the product pipeline.

Evidence terms on this page retain their existing project meanings: Runtime-confirmed, Static-confirmed, Implementation/CI-confirmed, Hypothesis / strong inference, Rejected / failed, and Pending.

Related current owners:

• Project status — current production/proof/pending dashboard and priority.
• Pickups and stage-local randomization — current ordinary-pickup behavior and stage-local production shuffle.
• Global item materialization and solvability — cross-stage logical pool, materializer/proof history, deterministic global retries, solver, required powers, and Temple Map question.
• Persistence, inventory, and lifecycle — pickup/inventory persistence and lifecycle mechanisms.
• XP and progression — native progression thresholds, reward behavior, and current lifecycle evidence.
• Native HUD and UI — current gameplay HUD/text/render-node capability and 1.0 HUD implementation reference.
• Presentation and branding — legal/title branding, edition text, boot phrase presentation, and visual acceptance.
• Web patcher and product behavior — browser/CLI product surface and current release boundary summary.
• Architecture overview — current subsystem boundaries.
• Runtime validation status — evidence scope by subsystem.

Required 1.0 behavior

R1 — Global cross-stage ordinary-item randomization

1.0 requires one global logical ordinary-item pool across the eight main stages rather than eight independent stage-local shuffles.

The current ordinary-pickup catalog contains 84 ordinary 0x30-byte records. The scripted Temple Map actor is not an ordinary record, but its physical location is the 85th shuffled randomizer check under R7. Logical Map item 0x0D is excluded from the reward pool. Therefore the final global generator permutes 85 destinations against 85 logical rewards. Three of the Fortress ordinary records are boss-defeat reward outputs for Kia, Jataaka, and Sareena: the boss defeat is the location/trigger, while the crystal is only the stock reward. A 1.0 global layout must therefore allow each of those three locations to spawn its assigned logical item and allow the crystal rewards themselves to move elsewhere.

A global placement cannot blindly copy the source record's movable identity tuple into another stage. The destination-stage materialization path must preserve the randomized item's actual identity, including:

• correct award semantics through a destination-safe callback/parameter path;
• correct collision/extents and presentation descriptor where required;
• the item's actual visual/model identity;
• a destination-local resource selector that resolves to the required resource;
• a guarded imported resource bundle when the destination does not already contain an equivalent resident resource.

A temporary design that awards item A while deliberately showing destination item B is not acceptable for 1.0.

The production materializer must also enforce guarded storage/allocation bounds, destination selector planning, file-table/resource updates where required, and deduplication rather than assuming an empty logical selector is free physical storage. Approved storage policy (2026-10-02): keep the supported clean input exactly 16 MiB, expand only the generated output to 32 MiB, and reserve appended ROM 0x01000000..0x017FFFFF as eight explicit 1 MiB destination-stage resource slots (Temple, Wind, Water, Earth, Prison, Fire, Bridge, Fortress). 0x01800000..0x01FFFFFF remains unassigned. The bounded Temple relocation proof is now Runtime-confirmed: stock stage-resource loading accepts a file-table range beginning above the original 16 MiB boundary, and ordinary Temple Herbs remained normal. Full eight-stage/full-seed runtime coverage remains a release validation limit; the maintainer has approved PR #137 promotion after bounded global-v2 gameplay.

Current state: Destination ownership and wrapper implementation are closed through Implementation/CI; first-item-swap v04 is Runtime-confirmed bounded. Cross-stage feasibility and representative resource conversion remain Runtime-confirmed in earlier bounded proofs. PR #129 now implements the researched destination-safe ordinary-item award/state contracts across all eight main stages, including Prison credential reconstruction and generic Bridge/Fortress activation-gate preservation. CI #1583 passes against current main while preserving lifecycle v06. The later first-item-swap v04 passed its bounded wrapper checks; PR #137 now connects global generation, validation, and materialization to normal seeded builds, with maintainer-approved promotion and bounded runtime evidence.

Acceptance criterion: a normal product build can materialize the global logical assignment into all affected destination stages with correct item visuals and awards, guarded bounds, and no reliance on proof-only allocation. The composed planner gate and destination-safe key/crystal/boss-reward path must be validated before global materialization is enabled in the browser/CLI product pipeline.

R2 — Deterministic global generation and deterministic retry attempts

The current stable SHA-256/Fisher-Yates approach remains the deterministic model, but 1.0 must apply deterministic generation to the global logical run rather than eight independent stage-local pools.

Rejected candidate layouts must not mutate hidden RNG state in a way that changes future regeneration. Retry state must be explicit. The required contract is conceptually:

candidate = H(namespace || user_seed || attempt_index || counter)

Attempt 0 is tested first, then attempt 1, then attempt 2, and so on until an accepted layout is found. Under the same MKMSZR version/rules, the accepted attempt and final layout must therefore be pure functions of the displayed seed.

Unrelated deterministic namespaces — including boot phrases, palette selection, HUD flavor text, progression-reward selection, or the required-Power-Upgrades target — must not advance the layout retry sequence.

The shared global product path uses a deterministic 10,000-attempt ceiling. The historical stage-local 1,000-attempt limit is superseded.

Current state: Implementation/CI-confirmed in PR #137, connected to the normal browser/CLI pipeline. Global-v2 promotion is maintainer-approved; bounded runtime evidence does not establish exhaustive full-run coverage.

Acceptance criterion: regenerating the same seed under the same 1.0 rules produces the same accepted attempt and byte-identical logical global layout even when one or more earlier candidates are rejected, and unrelated RNG features cannot alter that result.

R3 — Deterministic whole-run solvability validation

Every accepted 1.0 global layout must pass a whole-run progression validator before it is materialized as the final seed.

The validator must use the current researched stage/location requirements as its rules source. The legacy Lua fixed-point solver is useful for the overall algorithmic shape — repeatedly collect all currently accessible locations until no new location opens — but its access rules and final beatability predicate are stale/incomplete and are not authoritative for native 1.0.

The completion predicate must account for the selected required number of Power Upgrades. Powers as pickups is ON by default: exactly nine explicit Power Upgrade logical rewards are inserted into the 85-reward multiset before the global shuffle and advance the native tier in collection order. They are not chosen as nine destinations after shuffling. When OFF, those same nine source entries remain Herbs and powers come from stock XP; the solver requires no shuffled Power Upgrade items and preserves vanilla earned XP without additional XP simulation/accounting. The 2026-10-06 correction persists that earned XP across supported lifecycle re-entry by mirroring native current XP into existing MKSV +0x44 and restoring it at the established safe stage-init boundary. Focused proof v01 is Runtime-confirmed bounded by the maintainer; representative full global-seed coverage remains part of the final release gate. This build-time choice and the final count requirement are independent.

Required powers is a build-time Vanilla / Custom / Seed choice. Vanilla preserves the stock Fortress XP comparison at 5100: this takes eight pickup rewards but can be crossed with normal XP before tier 8, so it is displayed as a stock XP threshold rather than an exact count. Custom accepts 0..9; Seed selects 0..9 deterministically from a separate namespace, independently of any global-layout retries. Custom/Seed counts map to XP 0 or the matching native threshold. The current browser/CLI patch stage changes the guarded Fortress comparison, with the item solver enforcing the corresponding required shuffled upgrades when ON. Final-fight runtime coverage remains bounded; the gate is independent of pickup mode. The chosen setting must remain visible in the native randomizer HUD once implemented.

1.0 must expose a Shuffle Power Progression product option. When disabled, the nine native Power Ups remain in vanilla order. When enabled, the nine power slots use a deterministic seed-derived unlock order independent of the XP threshold values themselves: reaching native tier N (through a progression reward when Powers as pickups is ON, or earned XP when OFF) awards the shuffled power at slot N. The same order must drive actual move eligibility and the native Power Ups icon/help presentation.

The enabled shuffle has exactly one dependency rule:

• Ice Shatter must be placed after at least one of Ice Blast, Directional Ice, or Air Ice Blast.

Slide and Super Slide have no ordering dependency. Either may precede the other. Power-order generation must use its own deterministic namespace with explicit deterministic candidate/retry state, must not depend on global-layout retry count or other unrelated RNG consumers, and must not silently impose additional power dependencies. The 2026-09-27 v02 bounded proof Runtime-confirmed the first-two mechanism, and v04 subsequently Runtime-confirmed the generalized nine-gate/presentation mechanism on its tested order, including Super Slide before Slide and Ice Shatter after Air Ice Blast. The shared browser/CLI implementation is now present; the browser defaults the option ON while retaining an OFF choice. The final representative all-tier production-composition runtime gate remains.

The required-Power-Upgrades target must:

• use the selected Vanilla / Custom / Seed policy, with Seed generated deterministically from its own RNG namespace;
• be independent of global-layout retry count;
• be represented as required shuffled upgrades in the solver when pickup mode is ON, while independently preserving/configuring the actual native Fortress XP gate in both modes;
• be visible to the player through the randomizer HUD;
• preserve the current runtime-confirmed native threshold behavior for each collected progression reward when Powers as pickups is ON, and retain vanilla earned XP when it is OFF, without an additional solver-accounting gate.

The build-time Custom/Seed range is 0..9. Powers as pickups and Required powers are independent. OFF retains vanilla earned XP; no additional earned-XP simulation or validation gate is required. The solver requires zero shuffled Power Upgrade items in OFF mode because none exist in that pool. This does not change the Fortress gate: Vanilla retains the stock 5100-XP check, and Custom/Seed still apply their selected XP threshold in either mode.

Current state: the PR #137 whole-run fixed-point validator and independent Required powers gate are Implementation/CI-confirmed. Native pickup progression is Runtime-confirmed through XP 258/two tiers on bounded routes; all nine tiers and a representative full-seed production run remain Pending runtime coverage.

User-approved completion modes (2026-10-02): the browser/CLI global generator exposes two deterministic acceptance policies. All 85 available is the default and requires every shuffled destination to become reachable. Game beatable requires all 21 progression credentials plus the selected Power requirement, but does not reject a seed solely because an optional mundane check remains unreachable. Both use the same fixed-point access graph and deterministic retry sequence.

Acceptance criterion: every emitted 1.0 seed has been accepted by a deterministic fixed-point whole-run validator using the selected completion mode and finalized current access rules, including the required shuffled upgrades when pickup mode is ON; OFF retains vanilla earned XP and the independently selected Fortress gate without new XP-accounting validation. The same user seed, options, and rules must produce the same solver result and accepted attempt.

R4 — Native randomizer HUD

1.0 requires a native in-game HUD/UI that exposes the run state needed to play the seed. The legacy Lua overlay is a semantic reference only; exact visual parity and the Lua inventory implementation are not required.

Required information is:

• current check progress, including collected/total information useful for the current stage;
• required Power Upgrades and the player's current progression status;
• current inventory storage navigation state;
• key-item progress by stage;
• useful temporary pickup feedback.

The old Lua overlay called its storage indicator an inventory “page.” The native product instead uses four authoritative backing boxes. The reconciled 1.0 requirement is to expose the current native box/storage state, not to reintroduce Lua paging. The existing Runtime-confirmed BOX n OF 4 text satisfies only that part of the broader requirement.

A text-first implementation is acceptable if it communicates the required state reliably; geometric icon parity with the Lua overlay is not required.

Current state: Implementation complete / Production beta. Native text drawing and BOX n OF 4 remain Runtime-confirmed production components. The completed Inventory presentation is Runtime-confirmed on the bounded v21 TEST LAB route: colored stage credentials, true selected-item portraits/titles, per-stage STG CHECKS KEYS, current/required Power status, and total CHKS XX-85 check progress coexist with four-box state. Direct in-Inventory Items-mode Left/Right switching across all four authoritative boxes is also Runtime-confirmed bounded in full production-composition v03, including wraparound and empty-box navigation while preserving stock Power Ups horizontal behavior. Production uses the native-font-safe REQ. POWERS X-Y / REQ. XP 5100 forms rather than slash separators; the PR #148 correction is Runtime-confirmed in a ROM generated from the deployed webapp. v23 separately Runtime-confirms nonblocking temporary Power-pickup feedback under rapid adjacent collection. Final representative full-seed/lifecycle validation remains the acceptance gate.

Acceptance criterion: during normal gameplay, the player can determine the required run-state information above without external Lua/emulator UI, and the display remains correct across the lifecycle routes covered by final 1.0 validation.

R5 — HP, lives, continues, and run-reset lifecycle

2026-10-01 policy clarification: run settings are configurable at build time. Difficulty defaults to Very Hard; starting lives default to 5 with range 1..10; starting continues default to 3 with range 0..5; HP persistence defaults ON. When HP persistence is ON, damaged HP/current resources persist only across living stage departure/completion/re-entry; when OFF, living re-entry starts at full HP. Ordinary death and Continue always construct full-health replacement lives and retain stock resource decrements. Only true final no-continues Game Over clears shared run state; the next run uses the configured difficulty/lives/continues and normal starter inventory while preserving user GAME SETTINGS preferences. The exact v06 Very Hard / 9 / 5 / HP-ON composition remains the Runtime-confirmed reference case.

1.0 must define and implement the lifecycle of the actual current-run HP, lives, and continues values across:

• normal stage transitions;
• direct Safe Stage Select routes used by the product;
• the relevant title/load/re-entry boundaries;
• Game Over/new-run reset.

The legacy Lua startup writes — Very Hard, six lives, and four continues — are clues only. They do not establish the native current-run storage or prove preservation across stage transitions. Likewise, the Lua's life-related address does not establish a complete native lifecycle solution.

The preserve/reset policy must be established from current native static/runtime evidence, not inferred from the Lua startup configuration.

Game Over/new-game reset behavior is currently Pending for the shared randomizer state as well and must be reconciled with this lifecycle so a new run does not inherit state that belongs to the previous run.

Current state: Runtime-confirmed baseline plus configurable production implementation. Lifecycle v06 is Runtime-confirmed for Very Hard / 9 lives / 5 continues / HP persistence ON. The shared patch core parameterizes only the validated lifecycle immediates for difficulty/lives/continues; HP persistence OFF retains the stock final full-HP constructor store (the observed v05 behavior). Configurable variants are Implementation/CI-confirmed until exercised in a representative runtime build.

Acceptance criterion: the configured lives/continues and selected HP-persistence policy behave consistently at every defined lifecycle boundary, including direct selector routes; ordinary death/Continue retain full replacement HP; and Game Over/new run establishes a clean run using the configured defaults.

R6 — Configured difficulty invariant

Difficulty is a run invariant selected at build time, not merely a value written once at startup. The product exposes Very Easy / Easy / Medium / Hard / Very Hard and defaults to Very Hard.

The legacy Lua writes difficulty value 0x04 during initialization, but that is only historical evidence for the Very Hard value. The lifecycle patch owns the configured difficulty at fresh-run and reset boundaries and mirrors the same selected value into the native difficulty carrier.

Current state: Runtime-confirmed baseline plus configurable production implementation. Very Hard is Runtime-confirmed in lifecycle v06. Other selectable difficulty values use the same guarded lifecycle path and differ only in the configured/native difficulty immediates; they are Implementation/CI-confirmed pending representative runtime validation.

Acceptance criterion: the selected build-time difficulty remains stable throughout the supported run lifecycle and Game Over/new run restores the same configured value.

R7 — Temple scripted Map location

The Temple Map is not one of the 84 ordinary pickup records. It is a separate scripted Temple actor/location. 1.0 policy is now resolved: logical inventory item Map 0x0D is excluded from the randomizer item pool, while the scripted Temple location remains a special randomizer check.

Bounded proof v01 changed only the scripted callback's inventory argument from Map 0x0D to Herbs 0x04 at ROM 0x000CC540, leaving the scripted actor and all post-award Temple logic untouched. The user Runtime-confirmed that the location still appeared as the Map, awarded Herbs, and moved the elevator/platform normally. Bounded v02 then used Temple's native Herbs presentation, a dedicated MKSV header flag, and a re-entry helper; the user reported the complete route worked perfectly, including Herbs visual/award, elevator and rope progression, title -> Temple re-entry with the check still absent and progression correct, and Temple -> Wind continuation.

Consequences for 1.0:

• Map 0x0D is not a globally shuffled logical item;
• no cross-stage Map persistence or Temple -> Wind Map-cleanup workaround is required;
• the scripted Temple location must remain modeled explicitly as a special check, not as a fifth ordinary Temple pickup and not as an ordinary 85th record;
• its Temple progression/elevator side effect must remain attached to that physical location regardless of assigned reward;
• the assigned reward uses the same logical-award/materializer contract as the global item model; the Temple-specific Herbs representative path now proves the actor can carry a non-Map visual/reward without disturbing progression;
• collection persistence is implemented independently of the existing 84 ordinary-pickup bitset through MKSV header flags bit 0x0001.

Current state: Temple-specific mechanism Runtime-confirmed and integrated on the feature branch. Global assignment of arbitrary logical rewards remains part of the still-Pending global item materializer, not a separate Temple blocker.

Acceptance criterion: Temple-specific portion satisfied. The special location can carry a non-Map reward/visual, preserves the stock elevator/exit progression, and persists as collected outside the 84 ordinary-pickup machinery. Final 1.0 global-check accounting and arbitrary logical-reward assignment are covered by the global generator/materializer acceptance gates.

Existing systems that 1.0 depends on

These are not new requirements created by this page. They are current production dependencies whose behavior the final 1.0 composition must not regress:

Dependency	Current evidence relevant to 1.0
Ordinary pickup persistence	Production beta; representative Runtime-confirmed collection/restoration in every main stage, not exhaustive 84-location runtime coverage
Four-box inventory and foreign-key masking	Production beta; Runtime-confirmed switching/transition behavior on documented routes; Game Over/reset edge still pending
Pickup-driven XP progression	Production beta; Diagnostic B Runtime-confirmed XP 85/258, Temple -> Wind, and title -> Fire; full nine-tier runtime run pending
Safe Stage Select / flow bypasses	Production; Runtime-confirmed bounded routes
Browser/CLI shared patch core	Production beta; both surfaces use the same patch core and guarded ROM validation
Current native HUD text path	Production/Runtime-confirmed for BOX n OF 4; broader randomizer HUD Pending

A final full-seed pass validates the composition of these systems with the new global-run features; it does not convert untested combinations into exhaustive runtime confirmation.

Blockers and non-blockers

1.0 blockers

The following are release blockers under the current requirements:

1. production-safe global cross-stage item materialization in the normal seeded generator path; the destination-wrapper composition itself is Runtime-confirmed bounded, and PR #137 now connects the deterministic global generator/solver to it; remaining release coverage is broader runtime validation;
2. deterministic global shuffle and explicit deterministic retry attempts;
3. deterministic whole-run solvability validation, including finalized required-Power-Upgrades policy;
4. native randomizer HUD with the required run-state information;
5. production implementation of the resolved Temple scripted-check policy (arbitrary reward visual/materialization plus special-check persistence);
6. HP/lives/continues lifecycle plus Game Over/new-run reset behavior;
7. enforced Very Hard invariant;
8. representative final full-seed Runtime-confirmed validation after the above are composed.

Explicit non-blockers

The current project sources explicitly state that these are not 1.0 blockers:

• ordinary-enemy randomization;
• Reverse Elbow / foreign-move completion.
• Ice Blast -> Pickup action-cancel experimentation and hand-authored pickup-placement tooling; these are explicitly Post-1.0 / 4Fun research and do not change the 1.0 control or randomization contract.

Bosses and scripted encounters are also outside the ordinary-enemy system and are not implicitly added to 1.0 by this roadmap.

This page does not classify unrelated donor/presentation experiments as 1.0 requirements unless an owning requirement source explicitly promotes them later.

Dependency order

The current Project Status priority order gives the following 1.0 dependency chain:

Order	Gate	Why it comes here
1	Finish cross-stage resource/materialization production gate	The global logical layout cannot become a playable ROM until destination resources and award semantics can be materialized safely
2	Replace stage-local generation with deterministic global shuffle + whole-run solver	Generation/solver must operate on the finalized global item/materialization model and include deterministic retries plus required-Power-Upgrades target
3	Build the native randomizer HUD	HUD should consume the finalized global-run/check/progression state rather than an interim stage-local model
4	Resolve Temple Map, then HP/lives/continues lifecycle and Very Hard invariant	These are remaining run-lifecycle/progression invariants needed before declaring a whole run release-ready
5	Run final full-seed validation	Runtime release evidence comes only after the production composition exists

This ordering is a dependency/prioritization rule, not a claim that every lower item must wait for all design or documentation work above it.

Final 1.0 runtime-validation gate

The final release gate requires a representative full global seed on the normal production composition.

At minimum, that run must demonstrate:

• an accepted deterministic global layout produced by the production generator/solver;
• cross-stage randomized items rendering as and awarding the items actually assigned;
• progression through the complete run without a solver/materialization softlock;
• all nine progression reward tiers exercised in runtime with Powers as pickups ON, and earned-XP progression exercised with it OFF;
• the selected Vanilla / Custom / Seed Fortress requirement behaving as configured and shown in the HUD;
• the required HUD state remaining usable during the run;
• ordinary-pickup persistence and four-box/key-masking behavior remaining healthy in the composed build;
• the finalized Temple Map behavior;
• the finalized HP/lives/continues policy across the major lifecycle boundaries;
• the Very Hard invariant;
• the defined Game Over/new-run reset boundary.

The route must include the major lifecycle transitions relevant to the implemented policies, including normal stage progression and the documented direct/title re-entry boundaries where those systems are expected to survive.

Passing CI/static checks is necessary but does not satisfy this final gate. The completed route is Runtime-confirmed only for the tested seed/routes and must not be described as exhaustive proof of every possible 84-location/item combination.

Known requirement ambiguities still open

These are requirement questions, not implementation facts to be silently guessed:

1. Temple scripted-check integration: Map 0x0D inclusion is resolved — it is excluded from the logical pool. Remaining work is the special location's arbitrary assigned-reward materialization/visual identity, collection persistence, and explicit solver/check accounting.
2. Independent required-power settings: policy is resolved. Custom/Seed retain their selected Fortress XP gate in both pickup modes. The solver counts shuffled upgrades when ON; OFF retains vanilla earned XP without additional accounting. HUD presentation remains Pending.
3. Whole-run completion predicate: policy is resolved in PR #137: All 85 available or Game beatable, using the current 85-check graph and deterministic retry sequence. Representative full-seed runtime release validation remains Pending.
4. HP/lives/continues policy details: preservation is required to be defined from native evidence; the legacy startup values do not answer which current-run values survive each boundary.
5. Global retry ceiling: deterministic retries are required, but the interim stage-local limit of 1,000 attempts has not been established as the 1.0 global limit.

Requirement matrix

Requirement	Current state	Acceptance criterion	Technical owner	Dependency / blocker
Global cross-stage ordinary-item pool	PR #137 Implementation/CI-confirmed and integrated; promotion approved. The pool contains 84 ordinary locations and the scripted Temple check, excludes Map, and inserts nine upgrades before shuffling when enabled. Appended resource ownership is explicit in 32 MiB output; runtime evidence is bounded.	One global logical assignment materializes across eight stages with guarded destination resources/callbacks	Global-Item-Materialization-and-Solvability	Integrated; representative full-seed release coverage remains
Exact randomized-item visual/award identity	Prison five-import plus TEST LAB v26/v27/v31/v33 are Runtime-confirmed bounded evidence; Earth-key donor closure is Runtime-confirmed in v38; checkpoint-free award/progression behavior is Runtime-confirmed for Prison L1 and native Fire on bounded routes; Fortress five-import destination stress and Kia -> Potion boss-trigger/reward separation are Runtime-confirmed on bounded routes; guarded production integration and generalized three-assassin emission remain Pending	Every randomized location renders and awards its assigned logical item; no destination-graphic placeholder path	Global-Item-Materialization-and-Solvability	Blocker. Part of global materialization
Deterministic global shuffle	PR #137 Implementation/CI-confirmed and connected to the shared product path; promotion approved. Fisher-Yates spans all 85 destinations/rewards.	Same seed/version/rules -> same global logical layout	Global-Item-Materialization-and-Solvability	Implementation integrated; broader runtime release coverage remains
Deterministic retry attempts	Implementation/CI-confirmed. Explicit attempt indexing, isolated namespace, and 10,000-attempt product ceiling.	Same seed/version/rules -> same accepted attempt and layout after rejected candidates	Global-Item-Materialization-and-Solvability	Implementation integrated
Whole-run solvability validator	PR #137 Implementation/CI-confirmed, with All 85 available / Game beatable policies over the current 85-check graph.	Every emitted layout passes its selected completion policy	Global-Item-Materialization-and-Solvability	Broader full-seed runtime release coverage remains
Configurable required Power Upgrades	Independent Vanilla / Custom / Seed Fortress XP gate implemented/static in both pickup modes. Solver enforces shuffled upgrades when ON; OFF retains vanilla XP without an accounting gate.	Selected count/XP gate remains retry-independent and HUD-visible	Global-Item-Materialization-and-Solvability + XP-and-Progression	HUD and representative runtime release coverage remain
Native randomizer HUD	BOX n OF 4 Runtime-confirmed/Production; full HUD Pending	Native gameplay exposes checks, required/current progression, box state, key progress, and pickup feedback	Native-HUD-and-UI	Blocker. Best built after global state is finalized
HP/lives/continues lifecycle	Pending native trace/policy	Defined preserve/reset behavior passes normal transition, direct-selector, title/re-entry, and reset boundaries	Persistence-Inventory-and-Lifecycle	Blocker. After/alongside Temple Map lifecycle work
Game Over/new-run reset	Pending	New run clears/resets all state defined as run-scoped without corrupting stock/product lifecycle	Persistence-Inventory-and-Lifecycle + relevant feature owners	Blocker. Required before final full-seed gate
Very Hard invariant	Pending	Very Hard remains enforced across supported run lifecycle routes	Persistence-Inventory-and-Lifecycle / product runtime	Blocker. Required before final full-seed gate
Temple scripted check	Policy Runtime-confirmed; production integration implemented in PR #137	Map 0x0D stays excluded from the logical pool; the scripted Temple location remains an explicit special check, preserves its elevator/exit side effect, awards the assigned reward with correct visual identity, and persists independently of the 84 ordinary records	Global-Item-Materialization-and-Solvability owns special-check reward/materializer/solver behavior; Persistence-Inventory-and-Lifecycle owns special-check collection lifecycle	Integrated; representative full-seed runtime coverage remains
Full nine-tier progression runtime coverage	First two tiers/lifecycle routes Runtime-confirmed; all nine in one run Pending	All nine reward thresholds/tiers work in the final production composition	XP-and-Progression	Final validation blocker
Final representative full global seed	Pending	Production ROM completes the documented full-seed route with global items, solver, HUD, lifecycle, Map policy, Very Hard, and reset behavior composed	Runtime-Validation-Status records evidence; this page owns the release gate	Final blocker
Seeded Temple intro audio	Optional donor-backed product feature; Audio-1/Audio-2 seams and production carrier are Runtime-confirmed; integration is in PR #120	With valid MKT Rev. 2 donor, exactly one intro audio position is deterministically replaced from its approved pool; without donor, stock Temple audio remains untouched	Sounds-and-Music / Web-Patcher-and-Product	Non-blocker; bounded v06 closes its production-carrier runtime gate
Enemy randomization	Proof/research work exists; not production 1.0 scope	No 1.0 acceptance requirement	Enemy-Randomization	Non-blocker
Reverse Elbow / foreign-move completion	Proof/research work exists; not production 1.0 scope	No 1.0 acceptance requirement	Player-Actions-and-Special-Moves / MKT research owners	Non-blocker