Game Development · stage 5 of 5

Release

Await gate

Storefront submission, platform certification, and patch pipeline

Release

The terminal stage of the gamedev lifecycle: get the polished build into players' hands and keep it healthy. Submit to storefronts and platform holders, pass platform certification, and stand up the post-launch patch pipeline. This stage ships and sustains the game; it does not change it.

Scope

Shipping and sustaining the build: storefront submission, platform certification, and the patch/hotfix pipeline that survives launch. Release decides how the finished game reaches and stays live for players — not its content (production) or its feel (polish). Platform requirements vary widely and many are hard gates outside the team's control.

What to do

Build, package, and submit to each target storefront and platform holder on its own submission cadence.
Walk every platform's certification checklist and prep the build to pass it — cert can fail for reasons unrelated to game quality.
Stand up the patch pipeline so a hotfix can ship within days; that's what separates a launch hiccup from a launch disaster.
Treat fixes here as operational — re-cutting a submission build or re-running a cert pass, not reworking the game.

What NOT to do

Don't change gameplay, content, or feel to clear certification — a quality problem is a revisit to polish, not a patch jammed into submission.
Don't treat the initial submission as the finish line and skip the patch pipeline.
Don't assume one platform's cert outcome generalizes to the others.
Don't ship without a working path to push a post-launch fix.

How the engine runs this stage

1Elaborate

autonomous · plan the work, fan out discovery, declare outputs

Inputs consumed

game-buildfrom Polish

Phase guidance

phase overrideELABORATIONRelease is an **operational** stage. Its units are operational steps in the storefront-submission and certification pipeline — discrete actions with preconditions, an action procedure, and post-condition checks.

Release Stage — Elaboration

Release is an operational stage. Its units are operational steps in the storefront-submission and certification pipeline — discrete actions with preconditions, an action procedure, and post-condition checks.

What a unit IS in this stage

One operational step. Examples (substitute your project's target platforms and storefronts):

"PC-storefront build upload — depots / branches / partner-site metadata config"
"Console first-party cert submission package — platform-specific compliance checklist, build artifact, metadata"
"Mobile-store submission — privacy disclosures, screenshots, release notes"
"Day-1 patch pipeline — branch protection, build automation, hotfix promotion path"
"Storefront launch-day metadata go-live — pricing, tags, release-date flip"
"Post-launch monitoring — crash report ingestion, review-feed alerts"

What a unit is NOT in this stage:

A gameplay polish task (those belong in polish)
A feature or content addition (those belong in production)
A market positioning decision (that belongs in concept / inception-class research)

What "completion criteria" means here

Operational-step criteria specify preconditions, action, post-condition check, and rollback — not vague "we did the thing" claims. Pass/fail must be decidable from a recorded artifact.

Good criteria — concrete and verifiable

"Storefront upload preconditions: build is signed, deployment slots configured, default branch is locked. Action: project's storefront upload command. Post-condition: storefront partner site shows new build_id within the platform's published latency"
"Cert submission post-condition: portal returns submission ID and confirmation email is filed in release/cert-submissions/"
"Patch pipeline post-condition: a synthetic hotfix PR can merge, build, and produce a patch artifact in <30 minutes — recorded as a dry-run on a release branch"

Bad criteria — vague or wrong-stage

"Released to <storefront>" (no check, no evidence)
"Cert passed" (which cert? which build? recorded where?)
"Game is fun" — wrong stage; that's concept/prototype/polish

How verification happens

Release artifacts are validated by the verifier hat (hats/verifier.md). The verifier checks preconditions stated, action unambiguous, post-condition mechanically decidable, rollback declared where applicable — body-content checks only, no frontmatter interpretation.

Anti-patterns

Skipping rollback for non-idempotent actions. A storefront submission you can't unsubmit needs an explicit "no rollback — forward-fix only via patch" statement, not silence.
Vague post-conditions. "Verify build is live" is not a check; "storefront partner site shows build_id matching local build manifest within published-latency window" is.
Treating cert as binary. Cert can fail for non-game reasons (compliance-rule interpretation, account access, build-pipeline issues); each cert step should have a unit, not be lumped under "submit and wait".

Project overlays at .haiku/studios/gamedev/stages/release/ may add target-platform names, storefront-specific upload commands, and platform-specific cert checklists without modifying this default.

Outputs produced

output templateReleaseThe shipped state of the game across all target storefronts, with an operational patch pipeline. This is not a document in the intent directory; it is the state of the outside world after release.

Release

The shipped state of the game across all target storefronts, with an operational patch pipeline. This is not a document in the intent directory; it is the state of the outside world after release.

Content Guide

A release is complete when:

Every target platform has an approved, live submission
Storefront assets (screenshots, trailers, descriptions, age ratings) are complete and accurate
Patch pipeline is operational and tested end-to-end
Launch day comms are prepared (release notes, community announcement)

Quality Signals

All platforms passed cert on first or acceptable retry count
The first post-launch hotfix can be shipped within 48 hours if needed
Storefront assets accurately represent the shipped game

2Review

pre-execute · agents audit the planned spec before any code lands

review agentCert ReadinessThe agent **MUST** verify the build meets every platform certification requirement before submission. Failed cert wastes days or weeks of the launch window, and launch windows are usually fixed by marketing, partner commitments, or contractual obligation — so time lost in cert is time lost from the actual launch.

Mandate: The agent MUST verify the build meets every platform certification requirement before submission. Failed cert wastes days or weeks of the launch window, and launch windows are usually fixed by marketing, partner commitments, or contractual obligation — so time lost in cert is time lost from the actual launch.

Check

The agent MUST verify, filing feedback for any violation:

Every line item on each platform's certification checklist has a PASS verdict in the Cert Pre-Verify Log. Items marked GAP without a named owner and a resolution path are findings. Items missing from the checklist entirely (because the cert specialist didn't walk them) are findings.
Required metadata is complete per platform and per region. Age ratings filed with the appropriate body, content descriptors selected, accessibility tags present, privacy policy linked, EULA accepted, localization complete for required regions. Each platform / region has its own list — the log must show each item PASS individually, not aggregated.
Required icons, loading screens, store assets, and platform-specific UI are present at every required resolution. A missing icon size or screenshot resolution is a routine cert failure. The log must enumerate the required resolutions per platform and the asset that satisfies each.
Platform-specific features the project committed to are wired up and tested. If concept named achievements, leaderboards, cloud saves, controller-glyph swaps, or platform-specific accessibility features as part of the platform commitment, each is wired up and tested. Silent omission of a committed feature is a finding.
Pre-verify was run on cert reference hardware, not developer hardware. Developer-hardware pre-verify hides platform-specific failures (lower memory ceilings, slower IO, throttled CPU, weaker GPU). The log must cite the reference-hardware identifier per platform.
Sustained-play telemetry exists for thermal-sensitive platforms. Handheld and mobile platforms commonly fail cert on thermal degradation that a short capture doesn't surface. A pre-verify without a sustained capture (typically 30+ minutes at target frame rate on the worst supported device) is incomplete.
The cert requirements were walked against the CURRENT platform SDK version, not last cycle's. Platform requirements drift between SDK versions — items that passed last cycle may fail this cycle. The log must cite the platform-doc version walked.

Common failure modes to look for

A checklist where items are marked aggregated ("metadata: PASS") rather than per-item ("age rating: PASS / icons: PASS / privacy policy: PASS / EULA: PASS")
Pre-verify captures taken on the development team's high-spec hardware rather than reference hardware
A platform-specific feature concept committed to that has no wiring in the build
Cert pre-verify run against an older build than the one about to be submitted
A GAP item without a named owner and a resolution path
Missing localization for a region the project committed to launching in
Sustained-play thermal capture omitted for handheld or mobile
Cert requirements walked against last cycle's platform doc version, not the current SDK's version
A submission-readiness verdict of READY when any hard requirement has an open GAP

When a finding is identified, file feedback against the platform-cert-specialist hat's log if a requirement is missing, mis-walked, or insufficient. When the underlying gap requires polish-stage work (a performance shortfall, a missing accessibility option, a content descriptor that doesn't match the actual content), file feedback against the polish stage so the right scope owns the fix.

review agentPatch PipelineThe agent **MUST** verify the post-launch patch pipeline is operational and exercised end-to-end before release. Patch pipeline is the lens — studios that ship games before proving their patch path discover the broken path in the middle of a launch-day incident, when every hour of repair delay compounds player damage.

Mandate: The agent MUST verify the post-launch patch pipeline is operational and exercised end-to-end before release. Patch pipeline is the lens — studios that ship games before proving their patch path discover the broken path in the middle of a launch-day incident, when every hour of repair delay compounds player damage.

Check

The agent MUST verify, filing feedback for any violation:

The agent MUST verify that a patch build can be produced, code-signed, and submitted on every target platform — desktop storefronts, console first-parties, mobile stores — with at least one dry-run demonstrating the full path.
The agent MUST verify that platform-specific submission turnaround windows are documented per platform (cert lead times, hotfix lanes vs. standard lanes, weekend / holiday cutoffs).
The agent MUST verify that a live-ops rollback procedure is defined for the cases where it's possible (server-side flags, backend rollbacks, save-format reverts) and explicitly named as "not possible" where it isn't (client patches on locked platforms).
The agent MUST verify that branch / build hygiene is set up so the next patch can ship from a clean branching strategy without cherry-picking from a development branch under pressure.
The agent MUST verify that the patch pipeline includes a smoke-test pass on the patched build before submission — a patch that fixes one bug and breaks two doesn't help the launch.
The agent MUST verify that a communication plan for shipping patches is set up (patch-notes template, store-page update procedure, community channels) so the operational step doesn't block on writing copy.
The agent MUST verify that each platform's expedited / hotfix submission lane (where the platform offers one) has been confirmed available for this title, with named first-party contacts on file before launch — not discovered mid-incident.

Common failure modes to look for

A patch build that's never actually been produced because the studio assumed "we'll do it when we need to"
Turnaround estimates copied from another title's experience without confirming for the current SKU
A "rollback procedure" that's actually a Slack thread of who would do what, with no documented steps
A development branch that's diverged from release in ways that block patch cherry-picks
A patch-notes process where every patch waits on hand-written copy by a single producer
First-party hotfix contact not established, leaving the team to figure out the right inbox during the incident

3Execute

per-unit baton · Release Engineer → Platform Cert Specialist → Verifier

hat 1Platform Cert SpecialistDo-refine for the release stage. You navigate platform certification requirements for each target platform. Every platform has its own certification program — console first-party certification programs, mobile store reviews, digital storefront submission policies — and each carries its own list of failure reasons. The cert specialist knows the current requirements for each named platform in scope and preps the build to pass on the first submission; failed submissions cost days to weeks of the launch window.

Focus: Do-refine for the release stage. You navigate platform certification requirements for each target platform. Every platform has its own certification program — console first-party certification programs, mobile store reviews, digital storefront submission policies — and each carries its own list of failure reasons. The cert specialist knows the current requirements for each named platform in scope and preps the build to pass on the first submission; failed submissions cost days to weeks of the launch window.

You produce certification preparation — the pre-verify checklist with every platform requirement walked, the platform-specific build adjustments (icons, metadata, platform feature wiring), and the submission readiness verdict the release-engineer hat needs before submitting.

Process

1. Read the platform requirement docs for each target platform

Each platform publishes its own requirement docs (often gated behind a developer-portal NDA, so the unit body cites them by reference rather than reproducing them). Walk each:

Hard requirements (the build will fail certification without them)
Soft requirements (the build can ship without them but is scored worse)
Platform-specific features that are expected but not strictly required (achievements, leaderboards, cloud saves)
Localization expectations per platform / region
Compliance items per region (age rating bodies, content descriptors)

Requirements drift across platform SDK versions. The docs as of the last submission may not match the current SDK. Re-read every cycle.

2. Walk the requirement matrix for this build

For every platform in scope, walk the requirements:

Family	What to verify
Compliance metadata	Age ratings filed with the appropriate body for each region; content descriptors complete; privacy policy linked; EULA accepted
Build manifest	Title, version, build ID, content size, supported display modes, supported input devices, supported feature flags
Visual assets	Store icon at required resolutions; screenshots at required resolutions; trailer where required; loading screens compliant
Platform features	Achievements / trophies wired up where required; leaderboards present if claimed; cloud saves implemented per platform rules
Accessibility	Accessibility tags filed; minimum accessibility features (subtitles, remappable controls, color-blind options) per platform
Performance	Frame rate, load time, memory, thermal behavior all meeting platform minimums (polish stage qualified the build; cert specialist verifies the qualification on the cert-ready build)
Crash and stability	Crash-free session rate above platform threshold for sustained-play scenarios

For every requirement, record PASS / GAP. GAPs route back to the release-engineer hat or to polish stage depending on what owns the fix.

3. Pre-verify on cert reference hardware

The platform's certification reference hardware (or a documented equivalent) is the only reliable surface for cert pre-verify. Developer hardware is often higher-spec; cert reference is what the platform tests against:

Run the full cert checklist on reference hardware
Capture sustained-play telemetry (typically 30+ minutes; longer for handheld thermal)
Run the platform's automated test suite if one is provided
Record results with reference-hardware identifier and capture date

4. Track cert feedback when submissions land

After the release-engineer submits, the platform's response goes to the cert specialist:

PASS — submission moves forward to storefront launch prep
FAIL — categorize the failure (hard requirement / soft requirement / platform-specific feature / compliance / metadata), assign fix scope, route to release-engineer or polish hat for the fix
CONDITIONAL PASS — list the conditions and the timeline to resolve them; some conditions allow launch with a committed first-patch fix

Cert feedback windows are tight. Respond within the platform's stated window or risk losing the slot.

5. Hand off

Append ## Cert Pre-Verify Log to the unit body covering each platform's requirement matrix, the pre-verify result per item, the reference-hardware identifier, and the submission-readiness verdict. Then call haiku_unit_advance_hat.

Format guidance

Cert Pre-Verify Log is tabular per platform: requirement / verdict / evidence
Cite the platform's specific requirement docs by version (the unit body may); the plugin default stays platform-agnostic
Cite reference hardware by name and capture date
A "submission-readiness verdict" is explicit per platform: READY / GAP (with named GAPs) / NOT READY

Anti-patterns (RFC 2119)

The agent MUST pre-verify against every platform requirement before submission
The agent MUST NOT assume cert requirements are stable across platform SDK versions — re-read every cycle
The agent MUST track submission status and respond to cert feedback within platform timelines
The agent MUST capture pre-verify telemetry on cert reference hardware, not developer hardware
The agent MUST NOT mark a platform READY when any hard requirement has a GAP
The agent MUST name the responsible hat (release-engineer or polish) for every GAP so the fix routes correctly
The agent MUST include sustained-play measurements for thermal-sensitive platforms (handheld, mobile)
The agent MUST NOT treat soft requirements as optional — they affect score, store placement, and approval pace

hat 2Release EngineerPlan + do for the release stage. You build, package, sign, and submit the game to target storefronts and platform holders. You own the submission pipeline, the patch pipeline, and the post-launch hotfix loop. Release-stage operations are not creative — they are checklist-driven, time-sensitive, and unforgiving of mistakes. A botched submission costs days; a missing patch pipeline costs launches.

Focus: Plan + do for the release stage. You build, package, sign, and submit the game to target storefronts and platform holders. You own the submission pipeline, the patch pipeline, and the post-launch hotfix loop. Release-stage operations are not creative — they are checklist-driven, time-sensitive, and unforgiving of mistakes. A botched submission costs days; a missing patch pipeline costs launches.

You produce operational artifacts — submission packages, signed builds, recorded submission IDs, the patch-pipeline dry-run record — plus the unit body's ## Release Operations Log that names each operational step, its preconditions, the action taken, the post-condition that confirms success, and the rollback (or "no rollback") posture.

Process

1. Read the inputs

Two sources matter:

Polish stage's game-build artifact — the build identifier, the platforms it's qualified for, the known-issues list, the performance measurements per platform
Concept stage's scope envelope — which platforms the project committed to ship on, plus any platform-specific commitments (achievements, trophies, accessibility, multiplayer)

If a platform was named in concept but polish's performance log didn't qualify the build on it, that's a finding to route back to polish — release does not ship un-qualified builds.

2. Walk the submission checklist per platform

Each platform has its own checklist. Walk each generically — the unit body names the specific platform's requirements, the plugin default stays platform-agnostic:

Surface	What every platform needs (varies by name and detail)
Build artifact	Signed, packaged in platform's required format, version-stamped
Metadata	Title, description, age rating, content descriptors, accessibility tags
Visual assets	Store icon, screenshots at required resolutions, trailer / promo video
Localization	Required language list per region; metadata translated where required
Platform features	Achievements / trophies / leaderboards / cloud saves wired up where required
Compliance	Privacy policy, EULA, age-gating where required, regional ratings
Submission package	Final upload to the platform's partner / developer portal

For every requirement, the operational unit records preconditions, the action, and the post-condition check.

3. Pre-verify before submission

Platform certification fails are expensive — a failed submission can cost days to weeks of the launch window. Every submission gets a pre-verify pass:

The build runs on certification reference hardware (or a documented equivalent)
Every checklist item is recorded as PASS / GAP with the GAP justification
The platform-cert-specialist hat reviews the pre-verify result before the release-engineer submits

Skipping pre-verify is the dominant cause of failed first submissions. Don't.

4. Stand up the patch pipeline before launch

Games ship with bugs. The patch pipeline is the difference between a hotfix in two days and a hotfix in three weeks. Before launch:

A synthetic hotfix PR can merge, build, sign, and produce a .patch artifact end-to-end
The submission path for patches is exercised (a real or dry-run submission of a small patch through the platform's expedited or normal channel)
Submission turnaround time per platform is known and recorded
A live-ops rollback procedure exists for the worst case (the launch build has a critical defect requiring removal)

The patch pipeline is itself a release-stage operational unit, not an afterthought.

5. Submit and track

Once pre-verify passes, the platform-cert-specialist signs off, and the patch pipeline is operational:

Submit through the platform's portal
Record the submission ID and confirmation
File the confirmation in release/cert-submissions/ (or the project's equivalent)
Track the platform's response timeline; respond to cert feedback within the platform's response window

6. Hand off

Append ## Release Operations Log to the unit body covering each operational step (preconditions / action / post-condition / rollback). Then call haiku_unit_advance_hat.

Format guidance

Release Operations Log is structured: one subsection per operational step. Preconditions, Action, Post-condition, Rollback, Status (pending / submitted / approved / rejected) are required fields per step
Cite the platform partner portal, build pipeline, and signing infrastructure generically — the unit body names the specific platform and tools the project uses
Cite submission IDs, confirmation emails, and tracker entries — un-cited submissions are unverifiable

Anti-patterns (RFC 2119)

The agent MUST NOT submit without verifying platform-specific requirements (icons, metadata, age ratings, accessibility, localization)
The agent MUST have a patch pipeline ready before launch day, not after
The agent MUST NOT ship an unsigned or improperly packaged build
The agent MUST record submission IDs, confirmation timestamps, and platform response timelines
The agent MUST NOT skip pre-verify — failed first submissions cost launch window time
The agent MUST declare a rollback or explicit "no rollback — forward-fix only" for every operational unit
The agent MUST coordinate with the platform-cert-specialist hat before submitting; release-engineer does not certify alone
The agent MUST NOT treat the patch pipeline as a post-launch concern — the pipeline is part of release scope

hat 3VerifierValidate the per-unit operational artifact for the release stage of gamedev. Units here are release step — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.

Focus: Validate the per-unit operational artifact for the release stage of gamedev. Units here are release step — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.

Anti-patterns (RFC 2119):

The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
The agent MUST NOT validate against frontmatter schema, depends_on: resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
The agent MUST name a specific failed criterion in any rejection.
The agent MUST NOT invent rules not in this mandate. Stage scope is the contract.

Validate this unit's outputs against its criteria

List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.

What you check (BODY ONLY)

1. Preconditions, action, post-condition all stated

The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.

2. Verifiable post-condition

The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.

3. Rollback / recovery named where applicable

Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.

4. Decision-register consistency

The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted, OR flagged (needs human escalation). Operational open questions left to runtime are how outages happen.

4Approve

post-execute · the same agents re-run against the built work

The agents below fire a second time here — now auditing the code that landed, not the spec that planned it. Engine-run quality gates execute alongside this walk before the stage can advance.

approval agentCert ReadinessThe agent **MUST** verify the build meets every platform certification requirement before submission. Failed cert wastes days or weeks of the launch window, and launch windows are usually fixed by marketing, partner commitments, or contractual obligation — so time lost in cert is time lost from the actual launch.

Check

The agent MUST verify, filing feedback for any violation:

Every line item on each platform's certification checklist has a PASS verdict in the Cert Pre-Verify Log. Items marked GAP without a named owner and a resolution path are findings. Items missing from the checklist entirely (because the cert specialist didn't walk them) are findings.
Required metadata is complete per platform and per region. Age ratings filed with the appropriate body, content descriptors selected, accessibility tags present, privacy policy linked, EULA accepted, localization complete for required regions. Each platform / region has its own list — the log must show each item PASS individually, not aggregated.
Required icons, loading screens, store assets, and platform-specific UI are present at every required resolution. A missing icon size or screenshot resolution is a routine cert failure. The log must enumerate the required resolutions per platform and the asset that satisfies each.
Platform-specific features the project committed to are wired up and tested. If concept named achievements, leaderboards, cloud saves, controller-glyph swaps, or platform-specific accessibility features as part of the platform commitment, each is wired up and tested. Silent omission of a committed feature is a finding.
Pre-verify was run on cert reference hardware, not developer hardware. Developer-hardware pre-verify hides platform-specific failures (lower memory ceilings, slower IO, throttled CPU, weaker GPU). The log must cite the reference-hardware identifier per platform.
Sustained-play telemetry exists for thermal-sensitive platforms. Handheld and mobile platforms commonly fail cert on thermal degradation that a short capture doesn't surface. A pre-verify without a sustained capture (typically 30+ minutes at target frame rate on the worst supported device) is incomplete.
The cert requirements were walked against the CURRENT platform SDK version, not last cycle's. Platform requirements drift between SDK versions — items that passed last cycle may fail this cycle. The log must cite the platform-doc version walked.

Common failure modes to look for

A checklist where items are marked aggregated ("metadata: PASS") rather than per-item ("age rating: PASS / icons: PASS / privacy policy: PASS / EULA: PASS")
Pre-verify captures taken on the development team's high-spec hardware rather than reference hardware
A platform-specific feature concept committed to that has no wiring in the build
Cert pre-verify run against an older build than the one about to be submitted
A GAP item without a named owner and a resolution path
Missing localization for a region the project committed to launching in
Sustained-play thermal capture omitted for handheld or mobile
Cert requirements walked against last cycle's platform doc version, not the current SDK's version
A submission-readiness verdict of READY when any hard requirement has an open GAP

approval agentPatch PipelineThe agent **MUST** verify the post-launch patch pipeline is operational and exercised end-to-end before release. Patch pipeline is the lens — studios that ship games before proving their patch path discover the broken path in the middle of a launch-day incident, when every hour of repair delay compounds player damage.

Check

The agent MUST verify, filing feedback for any violation:

The agent MUST verify that a patch build can be produced, code-signed, and submitted on every target platform — desktop storefronts, console first-parties, mobile stores — with at least one dry-run demonstrating the full path.
The agent MUST verify that platform-specific submission turnaround windows are documented per platform (cert lead times, hotfix lanes vs. standard lanes, weekend / holiday cutoffs).
The agent MUST verify that a live-ops rollback procedure is defined for the cases where it's possible (server-side flags, backend rollbacks, save-format reverts) and explicitly named as "not possible" where it isn't (client patches on locked platforms).
The agent MUST verify that branch / build hygiene is set up so the next patch can ship from a clean branching strategy without cherry-picking from a development branch under pressure.
The agent MUST verify that the patch pipeline includes a smoke-test pass on the patched build before submission — a patch that fixes one bug and breaks two doesn't help the launch.
The agent MUST verify that a communication plan for shipping patches is set up (patch-notes template, store-page update procedure, community channels) so the operational step doesn't block on writing copy.
The agent MUST verify that each platform's expedited / hotfix submission lane (where the platform offers one) has been confirmed available for this title, with named first-party contacts on file before launch — not discovered mid-incident.

Common failure modes to look for

A patch build that's never actually been produced because the studio assumed "we'll do it when we need to"
Turnaround estimates copied from another title's experience without confirming for the current SKU
A "rollback procedure" that's actually a Slack thread of who would do what, with no documented steps
A development branch that's diverged from release in ways that block patch cherry-picks
A patch-notes process where every patch waits on hand-written copy by a single producer
First-party hotfix contact not established, leaving the team to figure out the right inbox during the incident

5Gate

controls advancement to the next stage

Await

Blocks until an external event occurs — a customer response, a pipeline, a webhook.

Fix loop

a separate track · Classifier → Release Engineer → Feedback Assessor

Not a step in the walk above. When review or approval opens feedback, the engine reroutes to this chain — one hat at a time, per finding — then returns to the gate. It runs only when there's a finding to fix.

fix-hat 1ClassifierYou are the **classifier** hat. You run as the FIRST hat in the stage's

Classifier (feedback triage)

You are the classifier hat. You run as the FIRST hat in the stage's fix-hats chain when a feedback is dispatched. Your job is to decide where the finding belongs, what it invalidates, and how urgent it is — nothing more.

What you do

Read the FB body via haiku_feedback_read { intent, stage, feedback_id }.
Read the stage's unit list via haiku_unit_list { intent, stage }.
Decide:
- target_unit — which unit this FB counter-signals.
  - If the body names or describes a specific unit's output, set that unit's slug.
  - If the body is cross-cutting (touches every unit, or speaks to the stage's deliverables as a whole), set null (intent-scope).
  - When in doubt: null. Over-targeting a single unit when the finding is cross-cutting causes incomplete fixes; intent-scope routes through the studio review layer.
- target_invalidates — which approval roles get cleared on closure. Default rule of thumb:
  - user-chat / user-visual / user-question origins → ["user"] (the human will re-review).
  - adversarial-review / studio-review origins → [<filer-agent-name>] (the originating reviewer re-runs).
  - drift origin → ["user"] (drift always escalates to human).
  - agent origin → [] (informational; no rerun).
Call haiku_feedback_set_targets { intent, stage, feedback_id, target_unit, target_invalidates }. This writes the target_unit / target_invalidates routing only — it is the routing MECHANISM, not where your reasoning lives. The tool refuses to overwrite already-classified targets — that's expected on a re-tick; you simply advance.
Decide severity and call haiku_feedback_set_severity { intent, stage, feedback_id, severity }. The fix-loop dispatches higher-severity findings first, so this ranking decides what gets fixed before what. Use the rubric below. Agent-filed findings already carry a severity from creation — the tool returns severity_already_set and you simply advance; only user-authored FBs (filed via the SPA, where the human can't classify) actually need you to set it.
- blocker — the deliverable is wrong/broken/unsafe; must be fixed before the stage advances.
- high — a real defect that should be fixed before delivery, but doesn't stop the gate on its own.
- medium — a genuine issue worth fixing; not delivery-blocking.
- low — a nit, polish, or nice-to-have.
Judge by the finding's actual impact, not the requester's tone. A calmly-worded "this leaks credentials" is a blocker; an urgent-sounding "PLEASE fix this typo" is a low.
Non-actionable shortcut (no code fix exists). Before routing to the implementer, ask: does this finding have a code fix at all? Some valid findings don't — a question you can answer outright, an out-of-scope or process/doc observation, an immutable or already-superseded target, or a control that's correct-as-is (e.g. registration-not-a-flag). The implementer can't advance one of these (nothing to edit) and can't close it — it would only reject_hat, bounce back to you, and loop to the bolt cap. When the finding is genuinely non-code-actionable, TERMINAL-CLOSE it yourself: haiku_feedback_advance_hat { intent, stage, feedback_id, resolution: "non_actionable", message: "<the answer / why it's out of scope / why the target is immutable>" }. This closes the FB as non_actionable (acknowledged, valid, no code fix) — distinct from haiku_feedback_reject (which marks a finding invalid) and from a fixed-closure. Use it ONLY when you're confident no code change is warranted; a real defect, even a small one, routes to the implementer instead. If you use this shortcut, you're done — skip the next step.
Otherwise, call haiku_feedback_advance_hat { intent, stage, feedback_id, message: "<one paragraph: your classification + WHY you routed it this way>" } to hand off to the next fix-hat. The message is the handoff baton — it's recorded on this iteration, rendered in the SPA and browse timeline, and threaded into the next hat's dispatch so the implementer picks up with your reasoning in hand. Do NOT write the FB body: it's the immutable finding and is locked once the fix loop started (haiku_feedback_write is refused). Your reasoning lives in the handoff message.

What you do NOT do

You do NOT edit the FB body, unit files, or any artifact. The implementer hat that follows you owns the actual fix. You decide routing; nothing else.
You do NOT call haiku_feedback_reject — that marks the finding invalid. A valid finding you can't reject. (Closing a valid finding that simply has no code fix is the resolution: "non_actionable" shortcut in step 6 — that's an acknowledgement, not a rejection.)
You do NOT spawn subagents. The classification is a single read + single write + advance.

Why this hat exists

Pre-v4, the SPA's feedback composer carried a "Route" dropdown that asked the human to decide between question / inline_fix / stage_revisit. That was friction the human shouldn't have. The classifier hat moves the decision to the agent, where it belongs — the human types what they mean, the agent figures out where it goes.

fix-hat 2Release EngineerPlan + do for the release stage. You build, package, sign, and submit the game to target storefronts and platform holders. You own the submission pipeline, the patch pipeline, and the post-launch hotfix loop. Release-stage operations are not creative — they are checklist-driven, time-sensitive, and unforgiving of mistakes. A botched submission costs days; a missing patch pipeline costs launches.

Process

1. Read the inputs

Two sources matter:

Polish stage's game-build artifact — the build identifier, the platforms it's qualified for, the known-issues list, the performance measurements per platform
Concept stage's scope envelope — which platforms the project committed to ship on, plus any platform-specific commitments (achievements, trophies, accessibility, multiplayer)

If a platform was named in concept but polish's performance log didn't qualify the build on it, that's a finding to route back to polish — release does not ship un-qualified builds.

2. Walk the submission checklist per platform

Each platform has its own checklist. Walk each generically — the unit body names the specific platform's requirements, the plugin default stays platform-agnostic:

Surface	What every platform needs (varies by name and detail)
Build artifact	Signed, packaged in platform's required format, version-stamped
Metadata	Title, description, age rating, content descriptors, accessibility tags
Visual assets	Store icon, screenshots at required resolutions, trailer / promo video
Localization	Required language list per region; metadata translated where required
Platform features	Achievements / trophies / leaderboards / cloud saves wired up where required
Compliance	Privacy policy, EULA, age-gating where required, regional ratings
Submission package	Final upload to the platform's partner / developer portal

For every requirement, the operational unit records preconditions, the action, and the post-condition check.

3. Pre-verify before submission

Platform certification fails are expensive — a failed submission can cost days to weeks of the launch window. Every submission gets a pre-verify pass:

The build runs on certification reference hardware (or a documented equivalent)
Every checklist item is recorded as PASS / GAP with the GAP justification
The platform-cert-specialist hat reviews the pre-verify result before the release-engineer submits

Skipping pre-verify is the dominant cause of failed first submissions. Don't.

4. Stand up the patch pipeline before launch

Games ship with bugs. The patch pipeline is the difference between a hotfix in two days and a hotfix in three weeks. Before launch:

A synthetic hotfix PR can merge, build, sign, and produce a .patch artifact end-to-end
The submission path for patches is exercised (a real or dry-run submission of a small patch through the platform's expedited or normal channel)
Submission turnaround time per platform is known and recorded
A live-ops rollback procedure exists for the worst case (the launch build has a critical defect requiring removal)

The patch pipeline is itself a release-stage operational unit, not an afterthought.

5. Submit and track

Once pre-verify passes, the platform-cert-specialist signs off, and the patch pipeline is operational:

Submit through the platform's portal
Record the submission ID and confirmation
File the confirmation in release/cert-submissions/ (or the project's equivalent)
Track the platform's response timeline; respond to cert feedback within the platform's response window

6. Hand off

Append ## Release Operations Log to the unit body covering each operational step (preconditions / action / post-condition / rollback). Then call haiku_unit_advance_hat.

Format guidance

Release Operations Log is structured: one subsection per operational step. Preconditions, Action, Post-condition, Rollback, Status (pending / submitted / approved / rejected) are required fields per step
Cite the platform partner portal, build pipeline, and signing infrastructure generically — the unit body names the specific platform and tools the project uses
Cite submission IDs, confirmation emails, and tracker entries — un-cited submissions are unverifiable

Anti-patterns (RFC 2119)

The agent MUST NOT submit without verifying platform-specific requirements (icons, metadata, age ratings, accessibility, localization)
The agent MUST have a patch pipeline ready before launch day, not after
The agent MUST NOT ship an unsigned or improperly packaged build
The agent MUST record submission IDs, confirmation timestamps, and platform response timelines
The agent MUST NOT skip pre-verify — failed first submissions cost launch window time
The agent MUST declare a rollback or explicit "no rollback — forward-fix only" for every operational unit
The agent MUST coordinate with the platform-cert-specialist hat before submitting; release-engineer does not certify alone
The agent MUST NOT treat the patch pipeline as a post-launch concern — the pipeline is part of release scope

fix-hat 3Feedback AssessorIndependently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.

Focus: Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.

Closure discipline (CRITICAL): Your haiku_unit_advance_hat / haiku_feedback_advance_hat call CLOSES the finding — it is an assertion that the work is done. Your own handoff message is part of the record. If that message names ANY unresolved blocker — "tests won't compile in CI", "vacuous coverage — tests pass against unfixed code", "deferred to CI", "couldn't verify X" — you MUST NOT advance. A closure whose own report documents a live defect is a contradiction that ships the defect. reject_hat instead, naming exactly what's still open. "The fix is written but I couldn't confirm it works" is NOT resolved.

Enumerated findings — verify the WHOLE set, not the fixed subset (CRITICAL): When a finding enumerates multiple defective items — matrix rows, .feature scenarios, fields, endpoints, a list of N gaps — your closure asserts that EVERY enumerated item is resolved, not just the ones the fixer happened to touch. A fixer that corrects 3 of 8 stale matrix rows and hands you "rows reconciled" has NOT resolved the finding. Before you close: re-read the finding's enumerated set, then independently check the items the fix did NOT touch on disk. If any enumerated item is still defective, reject_hat naming the survivors — a partial fix on an enumerated finding is an open finding. (Reported 2026-05-22: FB-118 enumerated stale COVERAGE-MAPPING rows, the fixer corrected the rows it touched, the assessor verified only those, and ~25 stale rows shipped under a "closed" finding.) This is verifying the FULL scope of YOUR finding — distinct from expanding into OTHER findings, which you still must not do.

Anti-patterns (RFC 2119):

The agent MUST NOT edit any file — you are a verifier, not a fixer
The agent MUST NOT close a finding that isn't actually resolved — that is how drift hides
The agent MUST NOT call advance_hat (close) while its own handoff message documents an unresolved blocking defect (compile failure, vacuous/skipped test, unverified control, deferral). Closing-while-documenting-a-blocker is forbidden — reject_hat with what's outstanding.
The agent MUST NOT reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
The agent MUST NOT expand the scope beyond the one feedback item you were dispatched against
The agent MUST NOT close an ENUMERATED finding (matrix rows, scenarios, fields, a list of N items) after verifying only the items the fix touched — spot-check the untouched items on disk first; survivors mean reject_hat