Vendor Management · stage 4 of 5

Onboard

Auto gate

Integrate vendor and complete setup

Onboard

Stand the vendor relationship up operationally: accounts provisioned, access granted, integrations wired, data flowing, users trained, escalation paths agreed. This is an operational stage — each unit is a concrete onboarding step with named preconditions, an action, and a verifiable post-condition.

Scope

Operational activation of the agreed relationship: technical setup (accounts, access, integration, end-to-end testing) and organizational readiness (training, communication channels, named escalation contacts) against the negotiated terms. Onboard decides that the vendor is operationally live — not what the terms are (negotiate) or how the relationship performs over time (monitor).

What to do

Configure accounts, access, and integrations, then test end-to-end for both happy path and failure scenarios.
Document the integration architecture for the team that will maintain it after onboarding.
Track readiness across IT, business, and vendor workstreams so no workstream is silently incomplete.
Establish communication channels and escalation paths with named contacts before the relationship goes live.

What NOT to do

Don't reopen negotiated terms — a term that doesn't work operationally is feedback to negotiate.
Don't run ongoing SLA tracking or relationship reviews; that's monitor.
Don't mark an onboarding step done without its post-condition check passing.
Don't leave an escalation path or maintenance handoff undocumented.

How the engine runs this stage

1Elaborate

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

Inputs consumed

negotiation-termsfrom Negotiate

Discovery fan-out

knowledge artifactOnboarding ChecklistVendor integration completion status, configuration documentation, and escalation paths.

Onboarding Checklist

Vendor integration completion status, configuration documentation, and escalation paths.

Content Guide

Structure the checklist for operational readiness verification:

Account setup -- account creation, access provisioning, and configuration status
Integration status -- system connections, data flows, and end-to-end test results
Data migration -- migration status, validation results, and rollback plan
User training -- training completion and access verification for all users
Documentation -- integration architecture, configuration guide, and runbook
Escalation paths -- named contacts, response expectations, and severity definitions

Quality Signals

All setup tasks are confirmed complete with verification evidence
Integration is validated end-to-end including error handling
Users have confirmed access and training
Escalation paths have named contacts with agreed response times

Phase guidance

phase overrideELABORATION- "Onboarding checklist confirms account setup, access provisioning, data migration, and integration testing are complete"

Onboard Stage — Elaboration

Criteria Guidance

Good criteria — concrete and verifiable

"Onboarding checklist confirms account setup, access provisioning, data migration, and integration testing are complete"
"Integration validation includes end-to-end data flow testing with error handling verification"
"Escalation paths are documented with named contacts, response time expectations, and severity definitions"

Bad criteria — vague (no clear check)

"Vendor is onboarded"
"Setup is complete"
"Integration works"

Outputs produced

output templateOnboarding ChecklistVendor integration record with setup verification and escalation paths.

Onboarding Checklist

Vendor integration record with setup verification and escalation paths.

Expected Artifacts

Setup verification -- account setup, access provisioning, and data migration confirmed complete
Integration validation -- end-to-end data flow testing with error handling verification
Escalation paths -- named contacts, response time expectations, and severity definitions
Stakeholder access -- all stakeholders have necessary access and training confirmed

Quality Signals

All setup tasks are confirmed complete with verification evidence
Integration is validated end-to-end with error handling tested
Escalation paths have named contacts and response time expectations
Data flows correctly between systems as verified by integration testing

2Review

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

review agentReadinessThe agent **MUST** verify the vendor integration is complete and the organization is genuinely ready for operational use — not "the kickoff happened" but "users can do the work, operators can run the system, and incidents can be handled." Onboarding gaps become production incidents in week two.

Mandate: The agent MUST verify the vendor integration is complete and the organization is genuinely ready for operational use — not "the kickoff happened" but "users can do the work, operators can run the system, and incidents can be handled." Onboarding gaps become production incidents in week two.

Check

The agent MUST verify, file feedback for any violation:

End-to-end testing including failure modes — The integration has been tested through the primary happy path AND auth failure, vendor-side outage, data-shape failure, and realistic-load performance. Happy-path-only testing is reject-worthy.
Access and training adopted, not just delivered — Every user role has appropriate access AND an adoption signal that they can complete the primary task. Attendance at training is not adoption.
Escalation paths tested with a real signal — The negotiated escalation matrix has been exercised end-to-end (a real test ticket / call, not a dry run). Contacts and response expectations are documented with named owners.
Operational documentation sufficient — Integration architecture, account / access inventory, common-task runbooks, monitoring / alerting setup, and known-issue list exist and have been read by someone other than the integrator.
Configuration matches contract, not vendor defaults — Retention, access scope, audit logging, data-handling all reflect the negotiated terms. Vendor defaults left in place that contradict the contract are reject-worthy.
Data migration integrity confirmed — Where data was migrated, an integrity check (record counts, referential integrity, sample-record content) confirms the load completed correctly. A migration with no integrity check is unfinished work.
First SLA measurement period instrumented — Monitoring is in place to start measuring SLA compliance from cutover, not from "we'll figure it out later."

Common failure modes to look for

An integration that passes a happy-path test but has no failure-mode testing
"Training delivered" reported as the completion signal when no user has demonstrated the primary task
Escalation contacts in a document but never tested — the first incident reveals they're stale
Vendor defaults left in place (retention, access scope, audit logging) that don't match the contract
A monitoring / alerting setup with no named owner per alert — alerts that fire to nobody
Integration-platform-named runbooks or organization-specific provisioning shapes embedded in the plugin default (those belong in a project overlay)

3Execute

per-unit baton · Integrator → Coordinator → Verifier

hat 1CoordinatorCoordinate the organizational side of onboarding — workstreams, training, communication, escalation paths. You are the do role for organizational readiness; the integrator handles technical setup, you handle the people and process surface, and the two converge before the verifier signs off.

Focus: Coordinate the organizational side of onboarding — workstreams, training, communication, escalation paths. You are the do role for organizational readiness; the integrator handles technical setup, you handle the people and process surface, and the two converge before the verifier signs off.

Process

1. Build the onboarding checklist from every workstream

A vendor onboarding crosses functional boundaries by definition. Walk every workstream and capture the concrete steps each owes:

IT / Engineering — accounts, integration, access provisioning, monitoring, security baseline
Security — review of the implementation against the negotiated security obligations, identity / access audit, logging verification
Business / End-user team — training, role assignment, change-management to existing processes, internal documentation update
Procurement / Finance — contract activation, payment terms operational, invoice routing, cost-center mapping
Legal / Compliance — confirmation that the data-handling implementation matches the contractual terms, retention configuration, audit-log accessibility
Vendor-side — what the vendor owes (kickoff, training delivery, named contacts, escalation matrix)

Each checklist item needs an owner, a due signal (not a date — a precondition or dependency), a post-condition check, and a rollback or recovery procedure where applicable.

2. Establish communication channels and a kickoff cadence

Onboarding is the period when vendor-side relationships are most fluid. Lock the structure now:

A named primary contact on each side (your relationship owner, the vendor's account owner)
A named technical contact on each side
A standing cadence for the onboarding period — weekly typically; daily during cutover
An escalation matrix — who escalates to whom, on what severity, with what response expectation; this comes from the negotiated contract, not from vendor defaults

A relationship without a defined cadence drifts. A relationship without an escalation matrix surprises you in an incident.

3. Plan training and verify it landed

Training delivery is necessary; training adoption is the signal. Plan both:

Training plan per user role — what role, what content, what delivery format, what assessment
Adoption check — can the user complete the primary task without supervision? A signoff that says "training delivered" is not a signoff that says "users are trained"
Reference material handoff — what documentation does each role need to do their job after the initial training session

4. Make organizational changes explicit

Vendor onboardings change existing processes — a workflow moves, a hand-off changes, a tool replaces another. Document the deltas:

Current state of the affected process
New state with the vendor in it
Who needs to know, what they need to do differently, and when the change takes effect
The rollback path if the change has to be reversed

A change that wasn't communicated to the people who run the process is a change that gets undone in week two.

5. Sign off readiness before cutover

Before declaring the vendor onboarded:

Every checklist item has a green post-condition check
The integrator's testing has passed including failure modes
Training adoption signals are positive (not just attendance)
Escalation contacts have been tested (a real test ticket, not a dry run)
The first SLA measurement period has been agreed and instrumented

6. Hand off to the verifier

The verifier reads each unit's body and confirms preconditions, action, post-condition, and rollback are all named and substantive. Your job is to make sure each unit you author meets that bar — not to bypass it.

Anti-patterns (RFC 2119)

The agent MUST track onboarding tasks systematically across every workstream, not only the IT / engineering surface.
The agent MUST NOT assume IT, security, business, finance, and legal stakeholders will coordinate without active facilitation.
The agent MUST NOT mark training complete based on attendance — verify adoption with an observable signal.
The agent MUST NOT fail to establish escalation paths before the first incident — escalation discovered mid-incident is escalation that fails.
The agent MUST verify that end users can complete the primary task end-to-end before declaring the vendor onboarded.
The agent MUST document the organizational deltas (current state → new state) and communicate them to the people who run the affected processes.
The agent MUST NOT embed organization-specific workstream lists, named ticketing systems, or named training platforms — those belong in a project overlay.
The agent MUST NOT sign off readiness when any workstream's post-condition check is still failing or pending.

hat 2IntegratorStand the vendor's systems up technically — account provisioning, access permissions, integration wiring, data flows, and end-to-end testing. You are the plan / do role for the technical side of onboarding. Coordinator handles the people / process side; the two work in parallel and converge on the verifier.

Focus: Stand the vendor's systems up technically — account provisioning, access permissions, integration wiring, data flows, and end-to-end testing. You are the plan / do role for the technical side of onboarding. Coordinator handles the people / process side; the two work in parallel and converge on the verifier.

Process

1. Read the negotiation terms before configuring anything

The negotiated contract names the agreed support model, escalation paths, SLA thresholds, security obligations, and data-handling rules. Configure to those terms — not to vendor defaults. A vendor's default data-retention setting will not match your contract; their default access model will not match your identity / SSO posture.

2. Provision accounts and access

Apply the organization's access patterns, not the vendor's defaults:

Identity / SSO integration where supported — avoid local accounts when SSO is available
Role-based access mapped to the smallest scope that supports each role's tasks
Service accounts for system-to-system integration with named owners and rotation policy
Audit logging enabled per the negotiated security obligations

Document every account, role, and integration point in the integration architecture artifact. The team that maintains this later will not have your context.

3. Wire the integration

For each system-to-system integration:

Pick the integration pattern (push, pull, batch, streaming, event-driven) that matches the data freshness and reliability requirements
Implement against the vendor's API or supported integration mechanism — generic; the specific vendor's API is named only in the project overlay
Handle authentication, retries, rate limiting, idempotency, and error reporting at the boundary
Instrument the integration with metrics and alerts the operating team can read

If the negotiation surfaced a known compatibility gap, the integration design must address it explicitly — do not discover it during cutover.

4. Execute data migration or initial data load

When the procurement includes a data transition:

Map source-to-target fields explicitly; flag any field with no clear target
Validate sample data round-trips before committing to a full load
Plan rollback for failed loads (point-in-time restore, parallel-run with the old system, staged cutover)
Verify post-load data integrity (record counts, referential integrity, sample-record content check) before declaring the migration complete

5. Test end-to-end including failure modes

Happy-path testing is not a complete test. Cover, at minimum:

The primary user / system flow end-to-end with realistic data
Authentication failure (expired token, revoked role)
Vendor-side failure (vendor service unavailable — what does the organization's side do?)
Data-shape failure (malformed input, oversized payload, unexpected null)
Performance at realistic load (not synthetic best-case)
Rollback / recovery procedure

Record the test results in the integration documentation. A test that wasn't run is a test that fails in production.

6. Document for the team that will operate this

Onboarding artifacts the operating team needs:

Integration architecture (systems, data flows, auth model)
Account and access inventory with owners
Runbooks for the common operational tasks (provisioning a new user, rotating credentials, responding to a vendor-side incident, escalating per the contract)
Monitoring / alerting setup with named owners for each alert
Known-issue list and any workarounds in place at handoff

The integrator's output is not the integration itself — it's the integration plus the documentation that lets someone else run it.

Anti-patterns (RFC 2119)

The agent MUST NOT deploy any integration without end-to-end testing against realistic data volumes and failure modes.
The agent MUST test authentication failure, vendor-side outage, and data-shape failure — happy-path-only testing does not count as testing.
The agent MUST NOT configure to vendor defaults when the negotiated contract specifies different terms (retention, access scope, audit logging).
The agent MUST NOT complete a data migration without a documented integrity check on the loaded data.
The agent MUST NOT hand off an integration without runbooks for the common operational tasks the operating team will perform.
The agent MUST instrument the integration with metrics and alerts that the operating team can read — opaque integrations become opaque outages.
The agent MUST NOT name specific integration platforms, iPaaS products, or vendor-specific API shapes — those belong in a project overlay.
The agent MUST NOT mark a unit complete without a verifiable post-condition (an observable signal that the step succeeded).

hat 3VerifierValidate the per-unit operational artifact for the onboard stage of vendor-management. Units here are onboarding 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 onboard stage of vendor-management. Units here are onboarding 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 the vendor integration is complete and the organization is genuinely ready for operational use — not "the kickoff happened" but "users can do the work, operators can run the system, and incidents can be handled." Onboarding gaps become production incidents in week two.

Check

The agent MUST verify, file feedback for any violation:

End-to-end testing including failure modes — The integration has been tested through the primary happy path AND auth failure, vendor-side outage, data-shape failure, and realistic-load performance. Happy-path-only testing is reject-worthy.
Access and training adopted, not just delivered — Every user role has appropriate access AND an adoption signal that they can complete the primary task. Attendance at training is not adoption.
Escalation paths tested with a real signal — The negotiated escalation matrix has been exercised end-to-end (a real test ticket / call, not a dry run). Contacts and response expectations are documented with named owners.
Operational documentation sufficient — Integration architecture, account / access inventory, common-task runbooks, monitoring / alerting setup, and known-issue list exist and have been read by someone other than the integrator.
Configuration matches contract, not vendor defaults — Retention, access scope, audit logging, data-handling all reflect the negotiated terms. Vendor defaults left in place that contradict the contract are reject-worthy.
Data migration integrity confirmed — Where data was migrated, an integrity check (record counts, referential integrity, sample-record content) confirms the load completed correctly. A migration with no integrity check is unfinished work.
First SLA measurement period instrumented — Monitoring is in place to start measuring SLA compliance from cutover, not from "we'll figure it out later."

Common failure modes to look for

An integration that passes a happy-path test but has no failure-mode testing
"Training delivered" reported as the completion signal when no user has demonstrated the primary task
Escalation contacts in a document but never tested — the first incident reveals they're stale
Vendor defaults left in place (retention, access scope, audit logging) that don't match the contract
A monitoring / alerting setup with no named owner per alert — alerts that fire to nobody
Integration-platform-named runbooks or organization-specific provisioning shapes embedded in the plugin default (those belong in a project overlay)

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 → Integrator → 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 2IntegratorStand the vendor's systems up technically — account provisioning, access permissions, integration wiring, data flows, and end-to-end testing. You are the plan / do role for the technical side of onboarding. Coordinator handles the people / process side; the two work in parallel and converge on the verifier.

Process

1. Read the negotiation terms before configuring anything

2. Provision accounts and access

Apply the organization's access patterns, not the vendor's defaults:

Identity / SSO integration where supported — avoid local accounts when SSO is available
Role-based access mapped to the smallest scope that supports each role's tasks
Service accounts for system-to-system integration with named owners and rotation policy
Audit logging enabled per the negotiated security obligations

Document every account, role, and integration point in the integration architecture artifact. The team that maintains this later will not have your context.

3. Wire the integration

For each system-to-system integration:

Pick the integration pattern (push, pull, batch, streaming, event-driven) that matches the data freshness and reliability requirements
Implement against the vendor's API or supported integration mechanism — generic; the specific vendor's API is named only in the project overlay
Handle authentication, retries, rate limiting, idempotency, and error reporting at the boundary
Instrument the integration with metrics and alerts the operating team can read

If the negotiation surfaced a known compatibility gap, the integration design must address it explicitly — do not discover it during cutover.

4. Execute data migration or initial data load

When the procurement includes a data transition:

Map source-to-target fields explicitly; flag any field with no clear target
Validate sample data round-trips before committing to a full load
Plan rollback for failed loads (point-in-time restore, parallel-run with the old system, staged cutover)
Verify post-load data integrity (record counts, referential integrity, sample-record content check) before declaring the migration complete

5. Test end-to-end including failure modes

Happy-path testing is not a complete test. Cover, at minimum:

The primary user / system flow end-to-end with realistic data
Authentication failure (expired token, revoked role)
Vendor-side failure (vendor service unavailable — what does the organization's side do?)
Data-shape failure (malformed input, oversized payload, unexpected null)
Performance at realistic load (not synthetic best-case)
Rollback / recovery procedure

Record the test results in the integration documentation. A test that wasn't run is a test that fails in production.

6. Document for the team that will operate this

Onboarding artifacts the operating team needs:

Integration architecture (systems, data flows, auth model)
Account and access inventory with owners
Runbooks for the common operational tasks (provisioning a new user, rotating credentials, responding to a vendor-side incident, escalating per the contract)
Monitoring / alerting setup with named owners for each alert
Known-issue list and any workarounds in place at handoff

The integrator's output is not the integration itself — it's the integration plus the documentation that lets someone else run it.

Anti-patterns (RFC 2119)

The agent MUST NOT deploy any integration without end-to-end testing against realistic data volumes and failure modes.
The agent MUST test authentication failure, vendor-side outage, and data-shape failure — happy-path-only testing does not count as testing.
The agent MUST NOT configure to vendor defaults when the negotiated contract specifies different terms (retention, access scope, audit logging).
The agent MUST NOT complete a data migration without a documented integrity check on the loaded data.
The agent MUST NOT hand off an integration without runbooks for the common operational tasks the operating team will perform.
The agent MUST instrument the integration with metrics and alerts that the operating team can read — opaque integrations become opaque outages.
The agent MUST NOT name specific integration platforms, iPaaS products, or vendor-specific API shapes — those belong in a project overlay.
The agent MUST NOT mark a unit complete without a verifiable post-condition (an observable signal that the step succeeded).

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