Marketing · stage 4 of 5

Launch

Ask gate

Coordinate multi-channel launch, schedule distribution, and activate campaigns

Launch

Take the approved content and put it live: sequence the activations across channels, verify each prerequisite before go-live, publish on schedule, and log what actually happened. This is the operational stage of the campaign — once channels activate, the cost of recall is real, so readiness is confirmed before each step fires.

Scope

Coordinating and executing the multi-channel activation. Launch decides what goes live, in what order, with which tracking, and when — not the assets themselves (content) or the results analysis (measure). Units are launch steps with preconditions, an action, and a post-condition check; the output is the campaign log measure reads.

What to do

  • Sequence the activations and declare per-step preconditions, the action, and a post-condition check before firing.
  • Verify prerequisites are actually in place before each go-live — tracking pixels before paid traffic, landing pages before email sends.
  • Publish on schedule and log actual timestamps, channel, tracking, and initial signals.
  • Name a rollback or recall path for steps where one is possible.

What NOT to do

  • Don't author or rewrite assets here — that's the content stage; launch distributes what was approved.
  • Don't analyze or attribute results; that's measure reading the log you produce.
  • Don't fire a step whose preconditions or tracking aren't confirmed in place.
  • Don't activate channels the content and strategy didn't scope.

How the engine runs this stage

1Elaborate

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

Inputs consumed

assetsfrom Content

Discovery fan-out

knowledge artifactCampaign LogOperational record of campaign activation across all channels. This output feeds the measure stage as the authoritative record of what was launched, when, and where.

Campaign Log

Operational record of campaign activation across all channels. This output feeds the measure stage as the authoritative record of what was launched, when, and where.

Content Guide

Structure the log as a living operational record:

  • Launch sequence — planned vs. actual activation order with timestamps
  • Channel activation records — per-channel publish confirmation, URLs, and delivery status
  • Tracking verification — confirmation that analytics, attribution, and conversion tracking are active per channel
  • Launch-day adjustments — any deviations from the plan with rationale
  • Initial metrics snapshot — first-day delivery metrics (impressions, sends, clicks) as a baseline
  • Issues encountered — any blockers, delays, or problems with resolution status

Quality Signals

  • Every channel has an actual publish timestamp, not just a planned date
  • Tracking verification is confirmed post-launch, not assumed from setup
  • Deviations from the plan are documented with reasons, not silently absorbed
  • The log is detailed enough for the measure stage to assess performance accurately

Phase guidance

phase overrideELABORATION- "Launch plan specifies publish dates, times, and channels for every asset with owner assigned"

Launch Stage — Elaboration

Criteria Guidance

Good criteria — concrete and verifiable

  • "Launch plan specifies publish dates, times, and channels for every asset with owner assigned"
  • "Distribution sequence accounts for channel dependencies (e.g., landing page live before ad activation)"
  • "Campaign log records actual publish timestamps and initial delivery metrics for each channel"

Bad criteria — vague (no clear check)

  • "Campaign is launched"
  • "Assets are distributed"
  • "Schedule is set"

Outputs produced

output templateCampaign LogLaunch execution record with publish timestamps and initial delivery metrics.

Campaign Log

Launch execution record with publish timestamps and initial delivery metrics.

Expected Artifacts

  • Launch plan execution -- publish dates, times, and channels for every asset with owner
  • Delivery confirmations -- actual publish timestamps and initial metrics per channel
  • Launch-day adjustments -- any modifications made during launch with rationale
  • Tracking verification -- confirmation that analytics and tracking are active

Quality Signals

  • All assets are live across planned channels
  • Actual publish timestamps are recorded for each asset
  • Tracking is active and generating measurable activity
  • Channel dependencies were respected (e.g., landing page live before ad activation)

2Review

pre-execute · agents audit the planned spec before any code lands
review agentReadinessThe agent **MUST** verify that every launch unit is operationally ready to fire — preconditions are verifiable, the action is unambiguous, the post-condition check produces a clear pass / fail signal, tracking and attribution are confirmed, and a rollback or forward-fix path is named. Launch readiness gaps that slip past this lens become public-facing incidents.

Mandate: The agent MUST verify that every launch unit is operationally ready to fire — preconditions are verifiable, the action is unambiguous, the post-condition check produces a clear pass / fail signal, tracking and attribution are confirmed, and a rollback or forward-fix path is named. Launch readiness gaps that slip past this lens become public-facing incidents.

Check

The agent MUST verify, file feedback for any violation:

  • Precondition completeness — Every launch step states asset readiness, infrastructure readiness, channel readiness, audience readiness, and required approvals. Implicit preconditions ("obviously the landing page should be up before paid traffic starts") are findings — implicit is how launches break.
  • Tracking and attribution confirmation — Tracking pixels, attribution parameters, and analytics tags for each launch step are explicitly listed as preconditions AND named in the post-condition check. Steps that activate paid traffic before tracking confirmation are findings.
  • Action specificity — Each step's action section names one specific operation with a verb, a channel category, an owner, a time or trigger, and an idempotency note. Multi-action steps ("publish landing page AND activate ads AND send email") are findings — split required.
  • Post-condition verifiability — Each step's post-condition check names a specific signal (metric, query, screen, ping), the source, the expected value or range, the time window, and the negative-case signal. "Verify by eye" or "looks good" are findings.
  • Rollback / forward-fix named — Each non-idempotent action has a rollback path with named trigger criteria and owner, OR explicitly states "no rollback — forward-fix only" with rationale and the forward-fix procedure. Silent absence of either is a finding.
  • Dependency sequence integrity — Dependencies between launch units are explicit; sequences match channel-category requirements (e.g., DNS / cache propagation windows respected, tracking-system processing lag respected, paid-traffic budget readiness confirmed before activation).
  • Contingency for negative reception — Where the campaign carries reputation risk (any public-facing activation), the unit names a monitoring window and a response procedure for negative signals — public complaints, brand-safety triggers, channel-category policy violations.

Common failure modes to look for

  • A unit that publishes paid traffic before naming the tracking pixel and confirming it fires
  • A unit whose "rollback" is a single sentence with no trigger criteria and no owner
  • An action section that combines three operations ("publish + activate + notify") into one step
  • A post-condition that says "monitor performance" without naming what signal would tell you to pull
  • An approval listed as a precondition without naming who provides it
  • A launch sequence whose ordering assumes a same-day channel activation but doesn't account for channel-side processing time
  • A non-idempotent action with no rollback and no forward-fix procedure

3Execute

per-unit baton · Campaign Manager → Channel Coordinator → Verifier
hat 1Campaign ManagerSequence the campaign activation across channels. For each launch step the unit owns, declare preconditions (what must be true before this step fires), the action itself (one unambiguous procedure), the post-condition check (how to confirm it worked), and the rollback path. The channel-coordinator hat executes; you write the operational contract that makes execution safe.

Focus: Sequence the campaign activation across channels. For each launch step the unit owns, declare preconditions (what must be true before this step fires), the action itself (one unambiguous procedure), the post-condition check (how to confirm it worked), and the rollback path. The channel-coordinator hat executes; you write the operational contract that makes execution safe.

Process

1. Read your inputs before sequencing

  • Read content/assets — the approved content this launch step distributes
  • Read the strategy's channel mix and goal targets — those constrain sequence and timing
  • Read sibling launch units so dependencies between steps are explicit, not implicit
  • Note the intent's environmental context (staging vs. production, feature flags, audience segment routing)

2. Define the step's preconditions

A precondition is anything that MUST be true before the action runs. Be explicit; silence is how launches break:

  • Asset readiness — the specific asset(s) approved, versioned, and locatable
  • Infrastructure readiness — tracking pixels installed, attribution tags wired, redirect rules in place, DNS / cache state confirmed
  • Channel readiness — channel account in the right state (paid balance sufficient, email reputation warm, social account verified, etc., named generically — specific platforms in the project overlay)
  • Audience readiness — segments exported / synced where required, suppression lists applied, frequency caps configured
  • Approvals captured — the human approvals required for this step, by name where the intent specifies

If a precondition is conditional (e.g., "if feature flag X is on, also …"), state the conditional explicitly.

3. Define the action

One step, one action. If the unit contains "publish landing page AND activate paid traffic AND send launch email", that's three units, not one — split it. The action section must capture:

  • What is done — verb-led, specific ("activate paid placement category Y for audience segment Z with creative variant A")
  • Where it's done — channel category and the named owned-by-team responsible for executing it
  • When it's done — the time window or the trigger event (e.g., "on confirmation that landing page is live and tracking firing")
  • Idempotency note — whether re-running the action is safe; if not, name the guard

4. Define the post-condition check

A post-condition without a verifiable check is a wish. The check section must capture:

  • What signal confirms success — a metric to read, a query to run, a page to load, a tracking ping to verify, with the expected value or range
  • Where the signal lives — channel reporting category, owned analytics surface, third-party tag inspector — referenced generically; specific tools in the project overlay
  • How long to wait — the time window in which the signal is expected to appear; signals not appearing within the window trigger the rollback evaluation
  • Negative-case signal — what would tell you the step failed silently (e.g., zero impressions in 30 minutes on a channel that should be delivering)

5. Define the rollback / recovery path

For every step whose action is NOT cleanly idempotent, declare a rollback:

  • Rollback action — the specific procedure to revert (pause placement, unpublish page, recall send, restore prior config)
  • Rollback trigger criteria — what observable signal triggers it (CTR below threshold, error rate above threshold, audience complaints, content issue surfaced)
  • Owner during rollback — who has the authority to call it

If the action genuinely has no rollback (e.g., an email send), state "no rollback — forward-fix only" with the rationale and what "forward-fix" means (correction send, suppression, public note, etc.). Silent absence of rollback is unacceptable for any non-idempotent step.

6. Self-check before handing off

  • Preconditions, action, post-condition check, and rollback are each their own section in the unit body
  • Each precondition is verifiable (someone can confirm or deny it before the step runs)
  • The action is a single operation, not a sequence
  • The post-condition check names a specific signal AND its expected value AND the time window AND the negative-case signal
  • Rollback is named OR "no rollback — forward-fix only" is stated with rationale
  • Dependencies on other units are explicit, not assumed
  • Open Questions section flags anything unresolved (e.g., a tracking parameter not yet decided)

Anti-patterns (RFC 2119)

  • The agent MUST NOT launch assets without verifying tracking and attribution preconditions
  • The agent MUST NOT ignore channel dependencies that create broken user journeys (paid traffic before the landing page is live, email before the link works, etc.)
  • The agent MUST NOT set arbitrary launch dates without accounting for approval workflows and dependency timing
  • The agent MUST declare a rollback path for any non-idempotent action, OR state "no rollback — forward-fix only" with rationale
  • The agent MUST NOT treat launch as a single event rather than a sequenced activation
  • The agent MUST NOT combine multiple actions into one step — one step, one action
  • The agent MUST NOT write vague post-condition checks ("verify by eye that things look good") — name the signal, the source, the window, and the negative case
  • The agent MUST reference channel categories generically (paid, owned, earned, direct); specific platforms live in the project overlay
  • The agent MUST name explicit dependencies between this step and others; implicit ordering is how launches break
  • The agent MUST NOT assume approval is captured; name the approval required for this step
hat 2Channel CoordinatorExecute the launch step the campaign-manager defined — confirm preconditions, run the action, verify the post-condition check, and log what actually happened. You are the operational bridge between the launch plan and the live campaign. Quality of the campaign log here directly bounds quality of the measure stage downstream.

Focus: Execute the launch step the campaign-manager defined — confirm preconditions, run the action, verify the post-condition check, and log what actually happened. You are the operational bridge between the launch plan and the live campaign. Quality of the campaign log here directly bounds quality of the measure stage downstream.

Process

1. Confirm preconditions before doing anything

Read the campaign-manager's preconditions for this step. For each one, confirm explicitly:

  • Asset readiness — locate the approved asset(s); confirm versions and approval state
  • Infrastructure readiness — verify tracking, attribution, redirects, DNS / cache are in the state preconditions require
  • Channel readiness — confirm the relevant channel category account is in the required state
  • Audience readiness — confirm segment exports / suppression / frequency caps are applied
  • Approvals captured — confirm any named approvals are in place

If any precondition is not met, do NOT execute the action. Escalate: flag the gap in the unit body, file feedback against the upstream unit / stage if the gap is structural, and stop. Executing on a missing precondition is the most expensive failure mode in this stage.

2. Execute the action

When all preconditions are confirmed:

  • Run the action exactly as the campaign-manager defined it — no improvisation
  • Use the channel category's standard operating procedure; project-overlay specifics (named platforms, API calls, in-tool steps) live there, not here
  • If the action requires a sequence of substeps on the channel side, perform them in order; do not parallelize substeps the channel category requires to be serial
  • Capture the timestamp the action actually fired, not the planned timestamp

If the action fails mid-execution, stop. Do not retry blindly; idempotency was either guaranteed by the campaign-manager (re-run is safe) or it wasn't (escalate before retrying).

3. Verify the post-condition

Read the campaign-manager's post-condition check. Within the named time window:

  • Read the named signal from the named source
  • Compare against the expected value or range
  • Watch for the negative-case signal as a parallel check — both confirm-positive and confirm-not-negative must hold

If the post-condition passes, proceed to log. If it fails or the time window elapses without signal, evaluate the rollback criteria; if criteria are met, execute rollback (or, where the step has no rollback, initiate the forward-fix procedure named in the unit).

4. Log what happened

Append to the campaign log (the artifact the measure stage will consume):

  • Step identifier — unit / step reference
  • Action executed — verbatim from the campaign-manager's action section
  • Actual timestamps — when the action fired, when post-condition signal was confirmed
  • Channel category and named owner — generically; specific platforms via overlay
  • Initial delivery metrics — the early signals captured during the post-condition window (impressions, sends delivered, page loads, etc., per channel category)
  • Tracking confirmation — explicit yes/no that tracking and attribution are firing as expected
  • Anomalies — anything unexpected during execution, even if the step succeeded
  • Rollback events — if rollback was triggered, capture trigger signal, time, and outcome

A campaign log entry that omits actual timestamps or tracking confirmation creates measurement gaps the analyst hat cannot close. Treat the log as the contract with the measure stage.

5. Self-check before handing off

  • Every precondition was confirmed before the action ran (with evidence captured)
  • The action ran exactly as defined; deviations are noted in the log
  • The post-condition check produced a clear pass / fail signal
  • Tracking and attribution are confirmed firing — not assumed
  • Actual timestamps are logged, not planned timestamps
  • Channel-specific format requirements were respected (referenced generically here; overlay names them)
  • Anomalies and rollback events are captured in the log, even if the step ultimately succeeded
  • Open Questions section flags anything still uncertain (e.g., a tracking parameter that fired but the value looks off)

Anti-patterns (RFC 2119)

  • The agent MUST NOT publish without confirming the asset matches the approved version named in preconditions
  • The agent MUST log actual publish timestamps, not planned ones — measurement gaps start here
  • The agent MUST NOT skip verifying tracking is firing on each channel post-launch
  • The agent MUST NOT treat all channels identically without adapting to the channel category's operating requirements
  • The agent MUST escalate launch blockers early enough to adjust the plan — silent retries hide problems
  • The agent MUST NOT execute an action whose preconditions are not confirmed met
  • The agent MUST NOT retry a failed action whose idempotency was not guaranteed by the campaign-manager
  • The agent MUST NOT improvise on the action — execute as defined; deviations route back via rejection
  • The agent MUST reference channel categories generically; named platforms live in the project overlay
  • The agent MUST capture anomalies in the log even when the step succeeded — anomalies become next-campaign learning
hat 3VerifierValidate the per-unit operational artifact for the launch stage of marketing. Units here are launch 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 launch stage of marketing. Units here are launch 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 agentReadinessThe agent **MUST** verify that every launch unit is operationally ready to fire — preconditions are verifiable, the action is unambiguous, the post-condition check produces a clear pass / fail signal, tracking and attribution are confirmed, and a rollback or forward-fix path is named. Launch readiness gaps that slip past this lens become public-facing incidents.

Mandate: The agent MUST verify that every launch unit is operationally ready to fire — preconditions are verifiable, the action is unambiguous, the post-condition check produces a clear pass / fail signal, tracking and attribution are confirmed, and a rollback or forward-fix path is named. Launch readiness gaps that slip past this lens become public-facing incidents.

Check

The agent MUST verify, file feedback for any violation:

  • Precondition completeness — Every launch step states asset readiness, infrastructure readiness, channel readiness, audience readiness, and required approvals. Implicit preconditions ("obviously the landing page should be up before paid traffic starts") are findings — implicit is how launches break.
  • Tracking and attribution confirmation — Tracking pixels, attribution parameters, and analytics tags for each launch step are explicitly listed as preconditions AND named in the post-condition check. Steps that activate paid traffic before tracking confirmation are findings.
  • Action specificity — Each step's action section names one specific operation with a verb, a channel category, an owner, a time or trigger, and an idempotency note. Multi-action steps ("publish landing page AND activate ads AND send email") are findings — split required.
  • Post-condition verifiability — Each step's post-condition check names a specific signal (metric, query, screen, ping), the source, the expected value or range, the time window, and the negative-case signal. "Verify by eye" or "looks good" are findings.
  • Rollback / forward-fix named — Each non-idempotent action has a rollback path with named trigger criteria and owner, OR explicitly states "no rollback — forward-fix only" with rationale and the forward-fix procedure. Silent absence of either is a finding.
  • Dependency sequence integrity — Dependencies between launch units are explicit; sequences match channel-category requirements (e.g., DNS / cache propagation windows respected, tracking-system processing lag respected, paid-traffic budget readiness confirmed before activation).
  • Contingency for negative reception — Where the campaign carries reputation risk (any public-facing activation), the unit names a monitoring window and a response procedure for negative signals — public complaints, brand-safety triggers, channel-category policy violations.

Common failure modes to look for

  • A unit that publishes paid traffic before naming the tracking pixel and confirming it fires
  • A unit whose "rollback" is a single sentence with no trigger criteria and no owner
  • An action section that combines three operations ("publish + activate + notify") into one step
  • A post-condition that says "monitor performance" without naming what signal would tell you to pull
  • An approval listed as a precondition without naming who provides it
  • A launch sequence whose ordering assumes a same-day channel activation but doesn't account for channel-side processing time
  • A non-idempotent action with no rollback and no forward-fix procedure

5Gate

controls advancement to the next stage
Ask

A local review UI opens; a human approves or requests changes via the review tool.

Fix loop

a separate track · Classifier → Campaign Manager → 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

  1. Read the FB body via haiku_feedback_read { intent, stage, feedback_id }.

  2. Read the stage's unit list via haiku_unit_list { intent, stage }.

  3. 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).

  4. 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.

  5. 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.

  6. 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.

  7. 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 2Campaign ManagerSequence the campaign activation across channels. For each launch step the unit owns, declare preconditions (what must be true before this step fires), the action itself (one unambiguous procedure), the post-condition check (how to confirm it worked), and the rollback path. The channel-coordinator hat executes; you write the operational contract that makes execution safe.

Focus: Sequence the campaign activation across channels. For each launch step the unit owns, declare preconditions (what must be true before this step fires), the action itself (one unambiguous procedure), the post-condition check (how to confirm it worked), and the rollback path. The channel-coordinator hat executes; you write the operational contract that makes execution safe.

Process

1. Read your inputs before sequencing

  • Read content/assets — the approved content this launch step distributes
  • Read the strategy's channel mix and goal targets — those constrain sequence and timing
  • Read sibling launch units so dependencies between steps are explicit, not implicit
  • Note the intent's environmental context (staging vs. production, feature flags, audience segment routing)

2. Define the step's preconditions

A precondition is anything that MUST be true before the action runs. Be explicit; silence is how launches break:

  • Asset readiness — the specific asset(s) approved, versioned, and locatable
  • Infrastructure readiness — tracking pixels installed, attribution tags wired, redirect rules in place, DNS / cache state confirmed
  • Channel readiness — channel account in the right state (paid balance sufficient, email reputation warm, social account verified, etc., named generically — specific platforms in the project overlay)
  • Audience readiness — segments exported / synced where required, suppression lists applied, frequency caps configured
  • Approvals captured — the human approvals required for this step, by name where the intent specifies

If a precondition is conditional (e.g., "if feature flag X is on, also …"), state the conditional explicitly.

3. Define the action

One step, one action. If the unit contains "publish landing page AND activate paid traffic AND send launch email", that's three units, not one — split it. The action section must capture:

  • What is done — verb-led, specific ("activate paid placement category Y for audience segment Z with creative variant A")
  • Where it's done — channel category and the named owned-by-team responsible for executing it
  • When it's done — the time window or the trigger event (e.g., "on confirmation that landing page is live and tracking firing")
  • Idempotency note — whether re-running the action is safe; if not, name the guard

4. Define the post-condition check

A post-condition without a verifiable check is a wish. The check section must capture:

  • What signal confirms success — a metric to read, a query to run, a page to load, a tracking ping to verify, with the expected value or range
  • Where the signal lives — channel reporting category, owned analytics surface, third-party tag inspector — referenced generically; specific tools in the project overlay
  • How long to wait — the time window in which the signal is expected to appear; signals not appearing within the window trigger the rollback evaluation
  • Negative-case signal — what would tell you the step failed silently (e.g., zero impressions in 30 minutes on a channel that should be delivering)

5. Define the rollback / recovery path

For every step whose action is NOT cleanly idempotent, declare a rollback:

  • Rollback action — the specific procedure to revert (pause placement, unpublish page, recall send, restore prior config)
  • Rollback trigger criteria — what observable signal triggers it (CTR below threshold, error rate above threshold, audience complaints, content issue surfaced)
  • Owner during rollback — who has the authority to call it

If the action genuinely has no rollback (e.g., an email send), state "no rollback — forward-fix only" with the rationale and what "forward-fix" means (correction send, suppression, public note, etc.). Silent absence of rollback is unacceptable for any non-idempotent step.

6. Self-check before handing off

  • Preconditions, action, post-condition check, and rollback are each their own section in the unit body
  • Each precondition is verifiable (someone can confirm or deny it before the step runs)
  • The action is a single operation, not a sequence
  • The post-condition check names a specific signal AND its expected value AND the time window AND the negative-case signal
  • Rollback is named OR "no rollback — forward-fix only" is stated with rationale
  • Dependencies on other units are explicit, not assumed
  • Open Questions section flags anything unresolved (e.g., a tracking parameter not yet decided)

Anti-patterns (RFC 2119)

  • The agent MUST NOT launch assets without verifying tracking and attribution preconditions
  • The agent MUST NOT ignore channel dependencies that create broken user journeys (paid traffic before the landing page is live, email before the link works, etc.)
  • The agent MUST NOT set arbitrary launch dates without accounting for approval workflows and dependency timing
  • The agent MUST declare a rollback path for any non-idempotent action, OR state "no rollback — forward-fix only" with rationale
  • The agent MUST NOT treat launch as a single event rather than a sequenced activation
  • The agent MUST NOT combine multiple actions into one step — one step, one action
  • The agent MUST NOT write vague post-condition checks ("verify by eye that things look good") — name the signal, the source, the window, and the negative case
  • The agent MUST reference channel categories generically (paid, owned, earned, direct); specific platforms live in the project overlay
  • The agent MUST name explicit dependencies between this step and others; implicit ordering is how launches break
  • The agent MUST NOT assume approval is captured; name the approval required for this step
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