game-rebuild-harness

name

game-rebuild-harness

description

Build, repair, operate, or audit an evidence-driven harness for reconstructing a small or mid-sized game from authorized reference videos, screenshots, play sessions, written rules, and existing code. Use when Codex must use its native search, media, image-generation, implementation, browser-playability, capture, and review capabilities through a fail-closed graph loop; turn observations into specifications and production assets; scaffold a reusable browser, Godot, Unity, or custom-engine harness; or assess whether a game recreation is faithful and safe to ship.

Game Rebuild Harness

Build the verification system before scaling implementation. Treat the target game as an observed system, not as a mood board.

Operating contract

Apply these rules throughout:

1. Separate evidence from interpretation. Label every material claim OBSERVED, CONFIRMED, INFERRED, UNKNOWN, or REPLICA_CHOICE.
2. Never call a recreation “1:1” while critical flows, timings, values, states, assets, or target-device captures remain unknown.
3. Do not let implementation code be the only specification. Persist manifests, contracts, scenarios, baselines, and decisions outside runtime code.
4. Drive user-visible journey tests through real input. Allow direct state setup only in isolated rigs and record it explicitly.
5. Reset every scenario independently. Keep long end-to-end journeys in addition to, not instead of, isolated scenarios.
6. Seed world, gameplay, presentation, and audio randomness separately. Fix all relevant streams during Golden Runs.
7. Keep rules, presentation, content data, harness control, and engine adapters separate.
8. Require independent automated checks and human review for subjective visual quality. The implementation agent cannot be the sole approver.
9. Track every asset’s provenance, license/authorization, generator, prompt or source reference, edits, and approval state. Never silently extract or reuse protected source-game assets.
10. Make unknowns visible. A documented unknown is safer than invented precision.
11. Select the engine with a recorded decision matrix tied to target platform, gameplay, iteration, automation, assets, determinism, CI, and release constraints. Do not choose from habit.
12. Report evidence, specification, implementation, scenario execution, assets, and fidelity verification separately. Never turn artifact counts into a single completion percentage.
13. After bounded self-help, escalate missing references, assets, gameplay facts, access, rights, technical direction, and repeated quality failures through workflow/human-assistance-queue.json. Never use a lower-quality substitute merely to keep the loop moving.

Choose the current mode

Determine the narrowest mode that satisfies the request:

• Bootstrap: create a harness in a new or existing project.
• Intake: guide the user through collecting recordings, screenshots, inputs, values, assets, and version metadata.
• Analyze: convert supplied evidence into observations, system maps, unknowns, and hypotheses.
• Specify: create manifests, state machines, interactions, capabilities, scenarios, budgets, and acceptance criteria.
• Implement: add adapters, deterministic runtime hooks, rigs, runners, metrics, or gates only when implementation is requested.
• Audit: inspect an existing recreation and report evidence gaps, harness bypasses, fidelity gaps, and release risks.
• Operate: run Golden Runs, visual surveys, performance suites, review packets, and release gates.

State the selected mode and current phase in the first progress update. Do not restart completed phases unless new evidence invalidates them.

Start by inspecting, not interviewing

Before asking the user for repository facts:

1. Inspect the repository, existing tests, engine, build commands, assets, and prior plans.
2. Read every reference file or linked conversation the user supplied.
3. Inventory available media and metadata.
4. Identify the single highest-value missing user input.

Ask one focused question at a time only when the answer is preference-dependent or cannot be discovered. Read human-assistance.md when a missing input can block quality: inspect local and retained evidence, perform one bounded lawful research/probe pass, then open an actionable request instead of silently stopping or inventing a fallback. Surface the highest-severity, highest-information request in the same task turn while unrelated graph work continues. If enough information exists to create a useful scaffold, create it and mark unresolved fields UNKNOWN.

Initialize a project harness

Default to a repository-local rebuild-harness/ directory. Run:

py <skill-dir>/scripts/init_harness.py --project <project-root> --game-id <slug> --game-name <name> --engine <browser|godot|unity|custom>

The initializer refuses to overwrite an existing non-empty harness. Preserve user work. Use the generated JSON files as canonical machine-readable artifacts and Markdown only for capture instructions, explanations, and human review.

After initialization, run:

py <skill-dir>/scripts/validate_harness.py --harness <project-root>/rebuild-harness --phase intake

Read contracts-and-schemas.md before changing canonical fields or adding an adapter.

Phase 0 — Scope and rights boundary

Record the target title, exact version/build, mode, platform, device, viewport, locale, session length, fidelity target, included screens, excluded systems, online dependencies, and asset authorization.

Define fidelity weights across gameplay, controls, economy, UX, presentation, audio, performance, and content. Replace “looks the same” with measurable acceptance criteria and named reference frames.

If the user cannot supply or authorize original assets, use original/generated replacements and record that as REPLICA_CHOICE. Reproduce observable behavior through clean-room observation; do not request reverse engineering, leaked source, or unauthorized asset extraction.

Choose the engine before implementation. Compare at least target-platform fit, gameplay/physics fit, real-input automation, iteration speed, asset/animation workflow, deterministic stepping, CI/export cost, and deployment constraints. Persist alternatives, weighted criteria, consequences, source refs, and revisit triggers in specs/engine-decision.json. An engine choice is provisional until its smallest input/physics/render/build rig passes.

Phase 1 — Guide evidence collection

Read intake-and-observation.md. Produce a tailored capture plan rather than a generic checklist.

Guide the user to collect, in priority order:

1. One uninterrupted canonical session from launch through restart or exit.
2. Focused recordings for every critical interaction, including success, disabled, insufficient-resource, interrupted, failure, and recovery states.
3. Stable screenshots for each screen, overlay, transition, object state, damage state, and target aspect ratio.
4. Inputs synchronized with video whenever possible.
5. Numerical observations: timestamps, prices, income, cooldowns, health, damage, spawn counts, probabilities, progression, and settlement values.
6. Audio samples or timestamped descriptions for music, ambience, UI, movement, combat, state change, and failure.
7. Version, device, frame-rate, graphics settings, locale, account state, unlocks, modifiers, and network conditions.

Never ask the user to capture everything at once. Give a “minimum useful pack,” validate it, then request the next highest-information clip.

Public-reference research agent

Read web-research.md before configuring providers or dispatching automated web research.

When public reference material is needed, create evidence/research-queue.json and dispatch a web-research-agent with the browser skill. The agent may search official pages, public walkthroughs, public screenshots, public video metadata, and other authorized sources. It must write evidence/source-index.json and evidence/reference-pack.json, retaining:

• query or navigation path, source URL/type, access time, build/device/viewport context;
• video timestamps or image/audio locators, retained frame paths, and hashes where locally retained;
• one claim per observation with OBSERVED, CONFIRMED, INFERRED, or UNKNOWN status;
• public-access and release-use rights separately.

Search hits and snippets are leads, not evidence. A source becomes usable only after an excerpt is retained and linked to a ledger claim. Contradictory sources remain separate. If browsing, playback, download, or rights status fails, record a blocked research task rather than inventing a result. Reference media may support measurement and review; it does not become a release asset without authorization.

Index media with:

py <skill-dir>/scripts/index_media.py --source <capture-folder> --harness <rebuild-harness>

When the user supplies an unpacked asset directory, archive export, recovered project art, or another local asset pack, run the read-only source-asset audit before Art Direction or asset generation:

py <skill-dir>/scripts/inspect_asset_pack.py --harness <rebuild-harness> --source <asset-folder> --expect-category ui --expect-category environment
# Add --expect-spine only when the declared target technique actually requires Spine.

The audit must inventory every non-metadata file with a hash, dimensions/alpha where available, taxonomy, directory family, duplicate group, sequence candidate, layered-animation component family, and animation-technique evidence. Treat skeleton-* rendered frames as baked sequences unless actual skeleton data, atlas metadata, and every declared texture page resolve together. The deterministic audit proposes human-assistance payloads but never mutates the protected queue itself; source-asset-auditor returns the applicable payload through the Runtime after visual sampling and bounded source discovery. Do not begin replacement generation until the supplied pack's coverage and authorization are known.

The indexer accepts media already saved under evidence/raw when used without a recursive copy. Use evidence/source-index.json for non-file sources such as official pages, public videos, documents, live sessions, user statements, and implementation runs.

Extract precise comparison frames when FFmpeg is available:

py <skill-dir>/scripts/extract_frames.py --video <clip.mp4> --output <rebuild-harness>/evidence/frames/<clip-id> --timestamps 0,0.5,1.25,3.0

Phase 2 — Build the evidence ledger

Create one ledger entry per independently useful claim. Every entry must include source, location/timestamp, claim, confidence label, affected systems, and contradiction status.

Reference a concrete local capture with source.media_id and broader provenance with source.source_id. OBSERVED and CONFIRMED require at least one valid source reference. Do not add URLs to the media index as fake files.

Use this promotion rule:

UNKNOWN -> INFERRED -> OBSERVED -> CONFIRMED
                     \-> REPLICA_CHOICE

• Promote to OBSERVED only when visible in an identified source.
• Promote to CONFIRMED only after repeat observation, direct controlled play, or corroborating evidence.
• Use INFERRED for plausible mechanics not directly visible.
• Use REPLICA_CHOICE for intentional implementation decisions.
• Preserve conflicting observations; do not average them silently.

Phase 3 — Decompose the whole game

Map the game across these layers:

1. session and core loop;
2. input and controls;
3. player/avatar states;
4. world, physics, collision, camera;
5. combat or primary interaction;
6. AI and spawning;
7. levels, modes, content, progression;
8. economy and numerical balance;
9. UI, onboarding, accessibility, localization;
10. art, animation, VFX, audio, feedback;
11. persistence, loading, platform services, networking;
12. build, performance, telemetry, release, rollback.

For each layer, list observed behavior, unknowns, dependencies, data ownership, failure modes, and evidence references. Do not expand implementation scope merely because a layer exists; mark exclusions explicitly.

Phase 4 — Specify interactions and states

Create:

• a screen/navigation graph;
• state machines for session, player, enemies, interactables, UI overlays, and persistence;
• an interaction matrix covering actor × target × state × input × precondition × effect × feedback × interruption;
• a presentation coupling classification for every interaction (none, state transition, transient contact, overlap-sensitive, attachment, carried, constraint, or projectile), including visual risk and linked fidelity cases;
• a timing table for transitions, animation locks, cooldowns, invulnerability, resource ticks, spawns, and camera changes;
• a contradiction and unknowns register.

Reject merged shortcut states that remove user-visible steps. If the reference requires move → approach → open → cross → close → approach bed → sleep, model each transition and its interruption behavior.

Phase 5 — Define capabilities and data contracts

Create one capability contract per bounded system. Each contract must declare:

• ID and version;
• purpose and non-goals;
• configuration schema;
• commands/inputs;
• emitted events/outputs;
• state snapshot fields;
• invariants;
• dependencies;
• asset slots;
• deterministic controls;
• rig scenarios;
• performance budget;
• evidence references;
• known limitations and rollback path.

Prefer content data over code branches. Implement a vertical slice before parallel capability production.

Phase 6 — Install a stable runtime adapter

Expose a narrow, versioned adapter instead of the complete game object. For browser games, target:

window.__rebuildHarness = {
  version: 1,
  reset(options),
  loadScenario(id, options),
  command(type, payload),
  stepFrames(count),
  stepMs(milliseconds),
  getSnapshot(),
  getMetrics(),
  captureFrame(name),
  drainEvents()
};

Keep the same semantic contract for Godot, Unity, and custom engines even when transport differs. Read engine-adapters.md and scenarios-replay-and-api.md.

The adapter may expose setup commands for isolated rigs. Journey tests must use public inputs and must not teleport past the behavior being tested.

Phase 7 — Build scenarios, Golden Runs, and rigs

Create three test classes:

• Rig: one capability in a minimal controlled scene;
• Scenario: one independently resettable behavior or interaction;
• Journey: a real user flow across systems.

Every scenario must include reset/seed, setup, timestamped actions, assertions, tolerances, evidence references, expected events, visual captures, budgets, cleanup, and ownership.

Include success, failure, boundary, interruption, adversarial seed, and recovery cases. Store Golden Runs only after the behavior is evidence-backed and human-approved.

Mandatory Playability Agent gate

A mechanic rig is never proof that a level or game is playable. Before any vertical slice, level, or core loop is counted as verified, dispatch an independent Playability Agent that:

• begins at the public launch/start state and reaches the declared terminal state;
• uses only retained public-input commands after reset, with zero setup commands after the first tested step;
• loads the production bundle and drives the production browser/device input surface rather than importing the simulation core;
• records actual key/pointer events and requires trusted browser/device events when the platform exposes isTrusted;
• reads only a documented read-only state/event projection, never calls reset, teleport, step, command, mutable runtime internals, or another privileged Harness method after launch;
• retains the complete input trace, checkpoints, terminal snapshot, and build/seeds;
• fails on death outside an expected failure route, stage timeout, unreachable target, or a configured no-progress window;
• fails on console errors, page errors, unhandled rejections, request failures, or missing production assets;
• saves the last snapshot, trace tail, and event slice at the first primary failure;
• re-runs from the beginning after every movement, collision, level-data, puzzle-order, or input change.

The deterministic core/input-adapter runner is a preflight only and contributes zero to Journey execution coverage. The independent Journey Verifier must review the production-browser/device trace and repeat the critical route on the target surface. A direct state placement that makes an exit or result assertion pass remains a Rig.

Do not equate one successful route with reasonable level design. Add a separate reasonableness gate that records collectible and mechanism coverage, classifies every puzzle element as evidence-backed required or optional, detects bypassed dependencies, tests recovery from likely misordered states, and fails closed while any requiredness or recovery result is unknown. A completion Journey may pass while the reasonableness gate fails. Strategy bots must use a declared human-latency profile: retain initial observation time, deliberation cadence, pointer/key action duration, and blocking-UI world-progress audits. An instantaneous fixed-tick bot is only a mechanics preflight and cannot prove human playability.

Do not equate a correct interaction outcome with correct interaction presentation. Apply this rule by presentation risk, not genre or mechanic. Every high-risk contact, attachment, carried-object, constraint, overlap-sensitive, projectile, mount, vehicle, mechanism, actor-to-actor, or multi-participant interaction needs a dynamic-interaction case in specs/animation-fidelity.json. Derive event-linked phases and variant dimensions from the observed interaction. Declare named participant anchor_contracts; an explicit geometry/state/camera/multiplicity variant_matrix; a target-scale composite_preview; consecutive transition_windows; and independent review. Require retained phase artifacts plus numeric, method-backed assertions for every applicable participant relation, connector, support/contact geometry, collision-to-visual offset, occlusion, render order, relative pose, timing, and one-frame discontinuity. A nominal sample cannot stand in for extremes, and a semantic success event never proves that the visible relationship was correct.

Gate every high-risk interaction on six separate proofs: semantic outcome, participant geometry, composited target-scale presentation, temporal continuity, interaction-derived variant coverage, and independent exact-candidate provenance. Failure on any axis reopens the smallest relevant implementation/art/capture/review subgraph. Never let success on one axis substitute for another.

Phase 8 — Build visual, animation, audio, and asset harnesses

Read visual-assets-and-audio.md before generating or importing assets.

Require:

• an Art Bible and style tokens;
• an asset brief per asset family;
• source/reference authorization and provenance;
• logical size, pivot, collision box, interaction box, layers, frame names, and animation timing;
• transparent-edge, dimensions, naming, compression, and import checks;
• in-game screenshots at actual target-device scale;
• fixed composition scenes, automated metrics, AI visual review, and a human judge set.

For every captured recreation candidate, require a named paired reference baseline, canvas-only target-size image, numeric machine-checkable thresholds, an independent PASS or REJECT report, and named human approval. Values such as pending, TBD, not-set, or human-calibration-later are not thresholds. Art Bible presence is specification only; it contributes zero to fidelity verification until a paired candidate passes all three review layers. Any P0 or blocking P1 finding keeps the Art Bible unlocked and release blocked.

Maintain independent specs/animation-fidelity.json and specs/audio-fidelity.json contracts. Each required case names evidence, mandatory observations, and numeric _min/_max thresholds; unresolved cases stay unknown and block the domain. Retain production captures in the declared raw report, including target build identity, paired reference IDs, local artifact paths, observations, and metrics. Evaluate both domains separately:

py <skill-dir>/scripts/measure_presentation_capture.py --harness <rebuild-harness>
py <skill-dir>/scripts/evaluate_presentation_quality.py --harness <rebuild-harness> --kind animation
py <skill-dir>/scripts/evaluate_presentation_quality.py --harness <rebuild-harness> --kind audio

Drive measurement from workflow/presentation-capture-plan.json. Require reports/production-presentation-capture.json to name the exact build, retain candidate hashes, and carry runtime event observations; derive video/audio metrics with FFmpeg into reports/presentation-quality-raw.json. Missing raw captures, unsafe/missing artifacts, unresolved contracts, changed hashes, missing reference pairs, or absent required metrics return FAIL. Static visual approval cannot substitute for animation or audio approval.

For dynamic-interaction animation cases, also retain phase_observations, anchor_evidence, variant_observations, composite_preview, transition_evidence, metric_evidence, and independent_review in the production capture manifest. Every declared variant combination must pass every required phase. The reviewer must differ from the producer and bind the verdict to the exact candidate hash. Treat untraceable numeric values, isolated asset previews, and phase snapshots without consecutive transition frames as missing evidence.

Agent handoff requirement

Do not treat a capability registry or asset brief as a production task. Read agent-runtime.md, then create and maintain three executable workflow artifacts:

• workflow/agent-pipeline.json: the dependency DAG, agent owner, required skill, deliverables, stop conditions, and missing-agent policy;
• workflow/agent-executors.json: Codex-native execution contexts, optional external adapters, capabilities, per-Agent bindings, and scoped write allowlists;
• workflow/human-assistance-queue.json: protected requests for missing evidence, assets, gameplay clarification, access, rights, technical direction, target-device input, or repeated fidelity failure;
• assets/asset-production-queue.json: one row per asset family with status, owner, next agent, blockers, deliverables, provenance, import QA, target-scale capture, and human approval.

The art path must be schedulable independently of gameplay implementation:

evidence -> art-direction -> asset-specification -> asset-generation
         -> technical-art -> visual-integration -> paired-fidelity-review
runtime + journey + reference evidence -> presentation-capture-agent
                                     -> animation-fidelity-review
                                     -> audio-fidelity-review

Source intake runs beside public research rather than inside production:

supplied/local asset roots -> source-asset-auditor -> observation-lead
authorized public sources -> web-research-agent ----^

source-asset-auditor is read-only and writes evidence/source-asset-inventory.json plus a human-readable audit. It does not copy supplied files into production, grant release authorization, or infer that loose images are Spine data. Missing expected categories or a missing required Spine triad becomes an assistance candidate scoped to the affected art/animation Agents; unrelated research, systems analysis, and playability work may continue.

asset-generation cannot start before the Art Bible and per-family specs are locked. Store the human decision separately in release/art-bible-approval.json, bind approval to the exact Art Bible SHA-256, and keep that file outside every art Agent write scope; an art Agent cannot approve itself. Bind family approvals in release/asset-family-approvals.json to the exact asset-manifest SHA-256 and keep that file outside production Agent write scopes. visual-integration cannot start before import QA and matching family approval. A missing art agent must produce a blocked queue item with an evidence gap and owner; it must never be silently skipped or counted as implemented. Placeholders can unblock behavior rigs only and always remain zero for production-asset coverage.

An Agent is not complete because its declared output paths already exist. Every pipeline row must carry an explicit lifecycle status and completion_record. Completion requires a timestamp, reviewer, retained evidence artifacts, all declared deliverables, resolved dependencies, and any required human approval. Draft files created during bootstrap remain drafts and must never cause downstream Agents to be skipped.

Treat the Harness itself as a directed control graph inside an explicit convergence loop. Keep plan_pipeline.py read-only and use run_agent_loop.py as the only Agent-state promoter. Use the current Codex session as the default executor, then run:

py <skill-dir>/scripts/run_agent_loop.py --harness <rebuild-harness> --preflight --host-capability fresh-codex-subagent
py <skill-dir>/scripts/run_agent_loop.py --harness <rebuild-harness> --host-capability fresh-codex-subagent
# Read and execute every emitted work packet with Codex native tools, write its exact result_path, then:
py <skill-dir>/scripts/run_agent_loop.py --harness <rebuild-harness> --host-capability fresh-codex-subagent --accept-result <rebuild-harness>/workflow/runtime/<attempt>/result.json
# After a real capability, evidence, dependency, or approval change resumes an accepted blocker:
py <skill-dir>/scripts/run_agent_loop.py --harness <rebuild-harness> --agent <agent-id> --resume-blocked --resume-reason "material context change"
# When a work packet opens a human-assistance request, record the human answer first:
py <skill-dir>/scripts/resolve_human_assistance.py --harness <rebuild-harness> --request-id <request-id> --responded-by <name> --summary <summary> --artifact <harness-relative-path>

The Runtime must generate a retained work packet and pre-work snapshot, let Codex execute it with native tools, audit changed paths, verify exact-attempt result IDs, hash every declared deliverable and evidence artifact, require passing quality checks, and reject missing, forged, stale, or over-scoped results. It may update an Agent completion record after acceptance; it may never grant human approval. Re-plan after every accepted transition and continue while continuation_contract.should_continue_in_current_turn is true. awaiting-native-result is a host handoff, not a user-facing stop. Persist accepted capability/evidence blockers and attempt limits in the graph; convert unresolvable blockers into deduplicated human-assistance nodes, surface the primary request, and resume only after its answer creates an audited material change. Treat a completed quality rejection as failed, not blocked; apply a defect-code-matched revision_route to reopen the smallest bounded production and review chain without adding a dependency cycle. Escalate one P0 or two same-class quality failures instead of looping unchanged. Keep Agent, automated-gate, asset, research, human-assistance, and human-approval frontiers separate so an unbound gate cannot masquerade as running Agent work. Verify native capabilities at execution time; an unavailable search, image-generation, browser, capture, or review capability produces a blocked result, never a fabricated completion. Execute production packets in the current Codex and independent-review packets in a native fresh-codex-subagent with un-forked context; attest that host capability on Runtime commands only after discovering the tool. Visual, animation, and audio may share one immutable-candidate review batch while retaining separate verdicts. External command adapters remain optional.

For a one-to-one claim, define the target as observed behavior and composition for a specific build, viewport, and rights scope. Keep exact unknowns open until measured. Every visual claim needs a paired reference/recreation capture, a machine-checkable metric or spatial assertion, an independent review, and named human approval. A populated Art Bible is specification, not visual fidelity.

When image generation is requested, invoke the available image-generation skill/tool. Generate coherent sheets or controlled families, not unrelated one-off images. For Spine, require approved layered sources with reconstructed occluded regions, paired motion clips, real skeleton/slots/attachments/atlas/textures, weighted deformation where rigid parts fail, key-pose and motion-arc matching, stable interaction anchors, transition mixing, event timing, multi-cycle loops, target-scale capture, and compatible export/runtime playback against spine_quality_policy plus quality-budgets.skeletal_animation; a moving skeleton or JSON-to-PNG lookup is not a quality pass. Open a spine-quality assistance request when source inputs are absent, a P0 appears, or the same defect is rejected twice.

For generated skeletal part sheets, retain the untouched generator output and prompt provenance, remove the approved chroma key non-destructively, and write a reviewed layout with normalized pivots, slot, bone, skin, and extraction mode. Run scripts/extract_rig_parts.py to produce alpha-trimmed attachments and a hash manifest. A candidate is invalid when a rectangle is empty or out of bounds, a filename is unsafe, a slot/skin binding is duplicated, an attachment hash drifts, or selected alpha pixels overlap across slots. Use largest-component only for a reviewed irregular attachment whose rectangular selection necessarily crosses nearby parts; keep broken rings and multi-island VFX on all-alpha. The extractor always emits candidate-unapproved; promotion remains an external exact-hash human decision.

Phase 9 — Numerical simulation and performance

Share production configuration with a headless simulator. Model novice, typical, expert, idle, adversarial, lucky, and unlucky policies. Check soft locks, runaway currency, dominant strategies, impossible progression, overflow, negative values, and sensitivity to changed parameters.

Measure frame time percentiles, memory growth, asset load time, draw calls/triangles when relevant, input latency, long-task stalls, network failures, and lowest-target-device behavior. Report distributions, not only averages.

Declare accessibility, localization, persistence, network/offline behavior, Harness isolation/security, privacy/telemetry, economy/monetization, mobile target devices, performance/soak, and observability in specs/nonfunctional-scope.json. Each dimension is required, excluded, or unknown; exclusions require a concrete rationale, required dimensions require named release gates, and unknown dimensions remain visible blockers to a broad completeness claim. Put numeric runtime thresholds in specs/quality-budgets.json. Missing raw measurements must produce a retained FAIL, never an inferred pass.

Phase 10 — Review, release, and memory

Read evaluation-release-and-memory.md. Run gates in dependency order:

schema -> build -> unit -> contract -> rig -> scenario -> Golden Run
-> save/load -> economy simulation -> visual -> performance -> smoke
-> independent review -> human approval

Build a review packet with:

py <skill-dir>/scripts/build_review_packet.py --harness <rebuild-harness>

Maintain reports/replication-readiness.json with explicit numerators, denominators, counting rules, and confidence for evidence coverage, specification readiness, implementation coverage, scenario execution, production assets, fidelity verification, and content breadth. A populated capability/scenario is specification only; it is not implemented or executed.

The readiness report must name the exact manifest target and be regenerated after newer evidence, research attempts, or unknown-resolution updates. A structurally valid but stale readiness report is a validation failure at implementation and release phases.

Regenerate the domain matrix before review and after any canonical artifact changes:

py <skill-dir>/scripts/assess_coverage.py --harness <rebuild-harness> --strict

reports/harness-coverage.json separates three claims for every domain: whether the Harness has a deterministic check, whether this project has executed and passed it, and whether the formal gate is approved. Never use Harness support as evidence that the recreation passed.

Write failures as reusable memory: symptom, evidence, root cause, rejected fixes, chosen fix, affected versions, verification, prevention rule, and expiry/recheck condition. Do not turn guesses into permanent rules.

Validation and completion

Validate after every phase transition:

py <skill-dir>/scripts/validate_harness.py --harness <rebuild-harness> --phase <intake|spec|implementation|release> --report <rebuild-harness>/reports/validation.json

Do not claim completion until:

• required evidence exists and contradictions are resolved or accepted;
• critical unknowns are zero for the declared scope;
• blocking human-assistance requests are zero and answered requests have been explicitly consumed by affected Agents;
• every required capability has a contract and an isolated rig;
• core journeys use real input and pass deterministically;
• high-risk dynamic interactions pass phase-linked spatial and layering checks, not only outcome assertions;
• visual baselines are captured at target dimensions;
• performance budgets pass on target tiers;
• asset provenance is complete;
• release smoke, rollback, and human approval are recorded;
• remaining deviations are enumerated, not hidden behind a single fidelity score.
• implementation and fidelity verification remain zero when no runtime or paired recreation evidence exists, even if specification validation passes.

Reference routing

• Read web-research.md for provider routing, research queues, scoring, deduplication, timestamped retention, and optional open-source components.
• Read intake-and-observation.md for user capture coaching, recording quality, evidence labels, and genre-specific probes.
• Read contracts-and-schemas.md for canonical artifact meanings and cross-file rules.
• Read human-assistance.md for escalation triggers, actionable request fields, protected responses, graph behavior, and audited resume.
• Read scenarios-replay-and-api.md for deterministic runtime APIs, scenario isolation, Golden Runs, and anti-bypass rules.
• Read visual-assets-and-audio.md for Art Bible, generated assets, Spine/sequence animation, audio, visual metrics, and judge sets.
• Read engine-adapters.md only for the selected engine.
• Read evaluation-release-and-memory.md for grading, CI, agent boundaries, failure memory, deployment, rollback, and audit output.

Final response contract

Report:

1. current mode and completed phase;
2. created or changed harness artifacts;
3. evidence coverage and highest-risk unknowns;
4. separate specification, implementation, scenario-execution, asset, and fidelity-verification readiness axes;
5. validations actually run and their results;
6. the single next highest-value user capture or engineering action;
7. known deviations, legal/provenance limitations, and release blockers.

Never report “complete” based only on compilation, a single happy-path video, or screenshots that were not tied to deterministic state.