Executive Strategy · stage 1 of 5

Landscape

Auto gate

Analyze market conditions, competitive intelligence, and strategic context

Landscape

The opening stage of the executive-strategy lifecycle: take the strategic question the user landed with and build the shared picture of the world it has to be decided in. The options, evaluation, and decision stages can't do useful work if this picture is missing or wrong.

Scope

Investigating the forces that bound the decision — market dynamics, competitor moves, regulatory pressure, organizational capability, and the uncertainties that matter most — and synthesizing them into one coherent view. Landscape decides what the strategic context is — it does not generate options (options), score them (evaluate), or recommend one (decide).

What to do

  • Frame each topic as an investigable surface and name the questions the analysis must answer.
  • Gather and validate the evidence — market data, competitor moves, capability signals — and cite it.
  • Surface the uncertainties that actually move the decision, not just the comfortable knowns.
  • Use frameworks like SWOT, Porter's Five Forces, or PESTEL as structuring concepts, never as a checklist every topic must fit.

What NOT to do

  • Don't generate or pre-favor strategic options — that's the options stage.
  • Don't score, rank, or stress-test anything — that's evaluate.
  • Don't make or pre-load a recommendation — that's decide.
  • Don't assert a market or capability claim without the evidence behind it.

How the engine runs this stage

1Elaborate

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

Discovery fan-out

knowledge artifactLandscape AnalysisMarket conditions, competitive intelligence, and organizational context that frames the strategic decision.

Landscape Analysis

Market conditions, competitive intelligence, and organizational context that frames the strategic decision.

Content Guide

Structure the analysis to enable informed option generation:

  • Strategic question -- the decision to be made with scope and boundaries
  • Market trends -- key trends with evidence-based impact assessment
  • Competitive landscape -- competitor positions, strategies, and likely next moves
  • Internal capabilities -- organizational strengths, weaknesses, and resource position
  • Key uncertainties -- the factors most likely to shape outcomes, with current assessment
  • SWOT synthesis -- integrated view connecting external environment to internal capabilities

Quality Signals

  • Trends are supported by current data from authoritative sources
  • Competitive intelligence reflects actual positions, not assumptions
  • Internal assessment is honest about weaknesses, not just strengths
  • Analysis is synthesized into a coherent view, not a data dump

Phase guidance

phase overrideELABORATION- "Market analysis identifies at least 5 trends with evidence-based assessment of their impact on the organization"

Landscape Stage — Elaboration

Criteria Guidance

Good criteria — concrete and verifiable

  • "Market analysis identifies at least 5 trends with evidence-based assessment of their impact on the organization"
  • "Competitive intelligence maps each competitor's strategic position, recent moves, and likely next actions"
  • "SWOT analysis connects each element to specific, verifiable facts rather than generic observations"

Bad criteria — vague (no clear check)

  • "Market is understood"
  • "Competition is analyzed"
  • "Landscape is mapped"

Outputs produced

output templateLandscape AnalysisMarket conditions, competitive intelligence, and strategic context assessment.

Landscape Analysis

Market conditions, competitive intelligence, and strategic context assessment.

Expected Artifacts

  • Market trends -- identified trends with evidence-based impact assessment
  • Competitive positions -- each competitor's strategic position, recent moves, and likely next actions
  • SWOT analysis -- each element connected to specific, verifiable facts
  • Decision context -- strategic framing for the decision at hand

Quality Signals

  • Market trends are evidence-based, not speculative
  • Competitive intelligence maps specific positions and recent actions
  • SWOT elements connect to verifiable facts, not generic observations
  • Data sources are validated and analytical framework is sound

2Review

pre-execute · agents audit the planned spec before any code lands
review agentRigorThe agent **MUST** verify that the landscape analysis is evidence-based, current, and synthesized into a coherent view that actually informs the strategic decision it's tied to. File feedback for any violation.

Mandate: The agent MUST verify that the landscape analysis is evidence-based, current, and synthesized into a coherent view that actually informs the strategic decision it's tied to. File feedback for any violation.

Check

  • Current evidence — Market trends, competitor positions, and regulatory signals are supported by data that's current enough for the framing's time horizon. A trend cited from a report older than the time horizon's halfway point is a finding unless the underlying conditions are demonstrably unchanged.
  • Source credibility — Every non-trivial claim has a specific citation (URL, doc path, dated interview, named standard). "Industry common knowledge" or "widely reported" without a source is a finding.
  • Competitive coverage — The analysis covers direct competitors AND adjacent threats / substitutes. A landscape that names only the obvious incumbents misses the disruption vector.
  • Internal capability honesty — The internal-capability portion (when present) is honest about weaknesses, not just strengths. A capability section that reads as a self-congratulation is a finding.
  • Framework fit — The structuring framework (SWOT, Porter's Five Forces, PESTEL, scenario planning, etc.) matches the topic. Force-fitting SWOT to a regulatory landscape, or PESTEL to a head-to-head competitive question, is a finding — name the framework that would fit better.
  • Synthesis, not data dump — The body delivers a point of view on what the evidence means, not just the evidence. A unit that lists facts without a synthesis section is a finding.
  • Decision linkage — The analysis names which downstream decision it informs. A landscape that floats free of any decision is an academic exercise and a finding.
  • Numerical consistency — Numerical claims (market size, competitor revenue, growth rates) are consistent across sibling units in this stage. Two units showing different numbers for the same fact is a finding against whichever unit you're reviewing.

Common failure modes to look for

  • A SWOT analysis where every Strength is a vague generalization ("strong brand", "talented team") without specific verifiable evidence
  • A competitor section that names only public, well-known players and skips emerging or adjacent threats
  • A trend that says "X is growing" without a number, a time window, or a source
  • An internal-capability section with no Weaknesses entries, or where the Weaknesses are obviously soft ("we could communicate better")
  • A "key uncertainties" section that lists generic uncertainties (regulation, economy) without naming the specific factors that would actually update the analysis
  • A framework that's filled in mechanically — every box populated — but with no synthesis tying the boxes together

3Execute

per-unit baton · Strategist → Analyst → Verifier
hat 1AnalystGather and validate the evidence the strategist's framing demands, and produce the synthesized landscape view. You are the do role for the landscape stage. The strategist hat told you what the topic IS, what frame to use, and what claims the synthesis must support or rebut. Your job is to fill that frame with evidence good enough to bet a strategic decision on.

Focus: Gather and validate the evidence the strategist's framing demands, and produce the synthesized landscape view. You are the do role for the landscape stage. The strategist hat told you what the topic IS, what frame to use, and what claims the synthesis must support or rebut. Your job is to fill that frame with evidence good enough to bet a strategic decision on.

Process

1. Read your inputs

  • The strategist hat's framing for this unit (topic scope, time horizon, key questions, structuring framework)
  • The intent's strategic question and any recorded Decisions
  • Sibling units' landscape work so far — your analysis must be consistent with theirs on shared facts (a competitor's revenue should not appear as two different numbers across units)

2. Gather evidence against each key question

For each key question the strategist named, list the evidence you'll need and where it comes from. Distinguish:

  • Primary sources — public filings, regulatory documents, named interviews, original research, stakeholder conversations with date
  • Secondary sources — analyst reports, industry studies, press coverage; treat as supporting, not authoritative
  • Inference — claims you're drawing from the evidence; mark them explicitly as inference, not as fact

Every non-trivial claim — numbers, market signals, competitor positions, regulatory direction — needs a citation. "Industry common knowledge" is not a source.

3. Validate data quality

Before synthesizing, sanity-check the evidence:

  • Recency — is the data current enough for the time horizon? A two-year-old market report often invalidates the analysis
  • Source credibility — who produced it, what's their stake in the conclusion, has it been independently confirmed?
  • Coverage — does the evidence span the scope the strategist named, or is it skewed toward one region / segment / competitor?
  • Conflicts — where do two sources disagree? Note the disagreement instead of picking the convenient one

Document data gaps explicitly. A known gap is a finding; a hidden gap is a defect.

4. Synthesize

Build the landscape view following the structuring framework the strategist named. The output is more than the evidence — it's a synthesized point of view:

  • What is happening — the trends, moves, conditions the evidence supports
  • Why it's happening — the underlying drivers
  • What it implies — what this means for the strategic decision the framing is tied to
  • What's uncertain — the factors most likely to change the picture, with current best-estimate direction and the signals that would update it

When using SWOT, Porter's Five Forces, PESTEL, or scenario planning, treat the framework as scaffolding — populate every box, but the value is in the synthesis tying the boxes together, not in the boxes themselves.

5. Self-check before handoff

  • Every key question the strategist named has a substantive answer
  • Every non-trivial claim has a specific source citation (URL, doc path, dated interview, named standard)
  • Every section the framework calls for is populated
  • Numerical claims are consistent across the body and with sibling units
  • Data gaps are documented as open findings, not hidden
  • The synthesis is a point of view, not a data dump

Anti-patterns (RFC 2119)

  • The agent MUST NOT rely on outdated reports without checking whether the underlying conditions have changed
  • The agent MUST NOT present data without assessing source credibility
  • The agent MUST NOT focus only on direct competitors while ignoring adjacent threats and substitutes
  • The agent MUST NOT collect data without a framework for what matters and why
  • The agent MUST NOT present a data dump and call it analysis — synthesis is the deliverable
  • The agent MUST NOT paper over conflicting sources by picking the convenient one
  • The agent MUST mark inferences as inferences, not as facts
  • The agent MUST document known data gaps as findings rather than hiding them
  • The agent MUST keep numerical claims consistent across the body and across sibling units in this stage
hat 2StrategistFrame the strategic question and synthesize the landscape into a coherent picture. You are the plan role for the landscape stage. The downstream stages — `options`, `evaluate`, `decide` — work off the picture you produce. If the framing is wrong, the option space is wrong; if the synthesis is wrong, the evaluation is wrong. You don't gather raw evidence (that's the analyst hat) and you don't validate it (that's the verifier) — you decide what the topic IS and what shape its analysis must take.

Focus: Frame the strategic question and synthesize the landscape into a coherent picture. You are the plan role for the landscape stage. The downstream stages — options, evaluate, decide — work off the picture you produce. If the framing is wrong, the option space is wrong; if the synthesis is wrong, the evaluation is wrong. You don't gather raw evidence (that's the analyst hat) and you don't validate it (that's the verifier) — you decide what the topic IS and what shape its analysis must take.

Process

1. Read your inputs

  • The unit's own success criteria and "topic shell" — what landscape surface is THIS unit about (regulatory, competitive, internal capability, macro environment, etc.)
  • The intent's overall strategic question
  • The decision register, if any decisions have already been recorded that constrain framing
  • Sibling units already drafted in this stage, so framing across units is consistent

2. Frame the topic

State the topic in one paragraph that names:

  • Scope — what's IN and what's OUT (e.g. "B2B SaaS competitors with > $10M ARR; excluding open-source projects")
  • Time horizon — what window matters (e.g. "12-month outlook; not 5-year")
  • Decision linkage — which downstream decision this landscape surface is supposed to inform
  • Key questions — three to five specific questions the analysis must answer, written so a reader can tell whether the answer was good

If the topic can't be framed cleanly, surface that as the first finding — vague topic shells become vague analyses.

3. Pick the right structuring device

Choose a generic structuring framework that fits the topic and name why:

  • SWOT when the topic is internal-vs-external balance
  • Porter's Five Forces when the topic is industry / competitive dynamics
  • PESTEL when the topic is macro-environment (political, economic, social, technological, environmental, legal)
  • Scenario planning when the topic is "what could happen" rather than "what is happening"
  • Capability map when the topic is internal — current capability, gap, build-vs-buy

Don't force a framework that doesn't fit. If none of the above apply, name the structure you're using and why ("topic-by-stakeholder", "topic-by-region", etc.).

4. Define what "good" looks like for the synthesis

Before the analyst gathers anything, write down what the synthesis must produce: a short list of claims the analysis must support or rebut, the evidence shape each claim needs (numbers? competitor moves? regulatory citations?), and how to tell whether the synthesis is honest or self-congratulatory.

5. Hand off

The analyst hat reads your framing and gathers evidence against it. Your output is on disk before the analyst runs.

Anti-patterns (RFC 2119)

  • The agent MUST NOT frame the question so narrowly that creative strategic options get precluded
  • The agent MUST NOT present raw data without a point of view on what the data means
  • The agent MUST NOT ignore internal capabilities and constraints when mapping the external landscape — an external-only landscape always overstates feasible options
  • The agent MUST NOT treat landscape as a one-time snapshot — name the conditions under which the framing would need to be re-examined
  • The agent MUST NOT pick a framework because it sounds rigorous; pick the one that fits the topic
  • The agent MUST name the downstream decision this landscape surface is supposed to inform — landscapes that don't tie to a decision become academic exercises
  • The agent MUST state the time horizon and scope explicitly — silence on either is how analyses sprawl
hat 3VerifierValidate the per-unit knowledge artifact for the landscape stage of executive-strategy. Units here are landscape analysis — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).

Focus: Validate the per-unit knowledge artifact for the landscape stage of executive-strategy. Units here are landscape analysis — knowledge artifacts that downstream stages consume. Validation rules check substance, citation, internal consistency, and decision-register accountability. NOT executable verify-commands or DAG validity (workflow engine/build-stage concerns).

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. Artifact answers its topic

The unit's title and first paragraph define the topic. The remaining body MUST deliver substantive content on that topic. Reject placeholders, content-free outlines, or redirects.

2. Sources cited

Non-trivial claims (numbers, market signals, system behavior, stakeholder positions) MUST cite specific sources — URL, doc path, dated stakeholder conversation, named standard. Reject "industry common knowledge" or unsourced numerical claims.

3. Internal consistency

Title, mission, and body must align. Numerical/categorical claims must be consistent across the body. Recommendations must follow from the evidence presented.

4. Decision-register consistency

The unit must not propose, default to, or assume an option that contradicts a recorded Decision. Cite the Decision ID in any rejection.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted with veto-style approval, OR flagged (needs human escalation).

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 agentRigorThe agent **MUST** verify that the landscape analysis is evidence-based, current, and synthesized into a coherent view that actually informs the strategic decision it's tied to. File feedback for any violation.

Mandate: The agent MUST verify that the landscape analysis is evidence-based, current, and synthesized into a coherent view that actually informs the strategic decision it's tied to. File feedback for any violation.

Check

  • Current evidence — Market trends, competitor positions, and regulatory signals are supported by data that's current enough for the framing's time horizon. A trend cited from a report older than the time horizon's halfway point is a finding unless the underlying conditions are demonstrably unchanged.
  • Source credibility — Every non-trivial claim has a specific citation (URL, doc path, dated interview, named standard). "Industry common knowledge" or "widely reported" without a source is a finding.
  • Competitive coverage — The analysis covers direct competitors AND adjacent threats / substitutes. A landscape that names only the obvious incumbents misses the disruption vector.
  • Internal capability honesty — The internal-capability portion (when present) is honest about weaknesses, not just strengths. A capability section that reads as a self-congratulation is a finding.
  • Framework fit — The structuring framework (SWOT, Porter's Five Forces, PESTEL, scenario planning, etc.) matches the topic. Force-fitting SWOT to a regulatory landscape, or PESTEL to a head-to-head competitive question, is a finding — name the framework that would fit better.
  • Synthesis, not data dump — The body delivers a point of view on what the evidence means, not just the evidence. A unit that lists facts without a synthesis section is a finding.
  • Decision linkage — The analysis names which downstream decision it informs. A landscape that floats free of any decision is an academic exercise and a finding.
  • Numerical consistency — Numerical claims (market size, competitor revenue, growth rates) are consistent across sibling units in this stage. Two units showing different numbers for the same fact is a finding against whichever unit you're reviewing.

Common failure modes to look for

  • A SWOT analysis where every Strength is a vague generalization ("strong brand", "talented team") without specific verifiable evidence
  • A competitor section that names only public, well-known players and skips emerging or adjacent threats
  • A trend that says "X is growing" without a number, a time window, or a source
  • An internal-capability section with no Weaknesses entries, or where the Weaknesses are obviously soft ("we could communicate better")
  • A "key uncertainties" section that lists generic uncertainties (regulation, economy) without naming the specific factors that would actually update the analysis
  • A framework that's filled in mechanically — every box populated — but with no synthesis tying the boxes together

5Gate

controls advancement to the next stage
Auto

The harness advances automatically — no human in the loop at this gate.

Fix loop

a separate track · Classifier → Strategist → 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 2StrategistFrame the strategic question and synthesize the landscape into a coherent picture. You are the plan role for the landscape stage. The downstream stages — `options`, `evaluate`, `decide` — work off the picture you produce. If the framing is wrong, the option space is wrong; if the synthesis is wrong, the evaluation is wrong. You don't gather raw evidence (that's the analyst hat) and you don't validate it (that's the verifier) — you decide what the topic IS and what shape its analysis must take.

Focus: Frame the strategic question and synthesize the landscape into a coherent picture. You are the plan role for the landscape stage. The downstream stages — options, evaluate, decide — work off the picture you produce. If the framing is wrong, the option space is wrong; if the synthesis is wrong, the evaluation is wrong. You don't gather raw evidence (that's the analyst hat) and you don't validate it (that's the verifier) — you decide what the topic IS and what shape its analysis must take.

Process

1. Read your inputs

  • The unit's own success criteria and "topic shell" — what landscape surface is THIS unit about (regulatory, competitive, internal capability, macro environment, etc.)
  • The intent's overall strategic question
  • The decision register, if any decisions have already been recorded that constrain framing
  • Sibling units already drafted in this stage, so framing across units is consistent

2. Frame the topic

State the topic in one paragraph that names:

  • Scope — what's IN and what's OUT (e.g. "B2B SaaS competitors with > $10M ARR; excluding open-source projects")
  • Time horizon — what window matters (e.g. "12-month outlook; not 5-year")
  • Decision linkage — which downstream decision this landscape surface is supposed to inform
  • Key questions — three to five specific questions the analysis must answer, written so a reader can tell whether the answer was good

If the topic can't be framed cleanly, surface that as the first finding — vague topic shells become vague analyses.

3. Pick the right structuring device

Choose a generic structuring framework that fits the topic and name why:

  • SWOT when the topic is internal-vs-external balance
  • Porter's Five Forces when the topic is industry / competitive dynamics
  • PESTEL when the topic is macro-environment (political, economic, social, technological, environmental, legal)
  • Scenario planning when the topic is "what could happen" rather than "what is happening"
  • Capability map when the topic is internal — current capability, gap, build-vs-buy

Don't force a framework that doesn't fit. If none of the above apply, name the structure you're using and why ("topic-by-stakeholder", "topic-by-region", etc.).

4. Define what "good" looks like for the synthesis

Before the analyst gathers anything, write down what the synthesis must produce: a short list of claims the analysis must support or rebut, the evidence shape each claim needs (numbers? competitor moves? regulatory citations?), and how to tell whether the synthesis is honest or self-congratulatory.

5. Hand off

The analyst hat reads your framing and gathers evidence against it. Your output is on disk before the analyst runs.

Anti-patterns (RFC 2119)

  • The agent MUST NOT frame the question so narrowly that creative strategic options get precluded
  • The agent MUST NOT present raw data without a point of view on what the data means
  • The agent MUST NOT ignore internal capabilities and constraints when mapping the external landscape — an external-only landscape always overstates feasible options
  • The agent MUST NOT treat landscape as a one-time snapshot — name the conditions under which the framing would need to be re-examined
  • The agent MUST NOT pick a framework because it sounds rigorous; pick the one that fits the topic
  • The agent MUST name the downstream decision this landscape surface is supposed to inform — landscapes that don't tie to a decision become academic exercises
  • The agent MUST state the time horizon and scope explicitly — silence on either is how analyses sprawl
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