Mandate: The agent MUST verify the close is operationally complete — every charter deliverable has recorded acceptance, every open item has a disposition, every ongoing surface has a recorded transfer, every contractual obligation is confirmed, and lessons learned are specific enough to transfer. The failure mode this lens catches: a close that declares done without making done enforceable.

Check

The agent MUST verify, file feedback for any violation:

• Deliverable acceptance evidence — every charter deliverable has named acceptance evidence (signed document, recorded confirmation, completed demo), an accepting stakeholder, and a date. Acceptance asserted without recorded evidence is rejected.
• Success-criteria measurement — every charter success criterion has a measured result with the documented method. Silently dropped criteria are rejected.
• Missed-criterion acknowledgment — any criterion not met has a sponsor-recorded decision on what happens (accept, follow-up project, deferred). Missed criteria without acknowledgment are rejected.
• Ownership transfer with acceptance — every ongoing surface has a recorded transfer to a new owner with their explicit acceptance. Transfers without recorded acceptance are rejected.
• Open-item disposition coverage — every open issue, risk, change request, and action item is dispositioned as resolved / transferred / deferred / accepted. Silent items are rejected.
• Contractual / compliance completion — every contractual or compliance obligation from the charter is confirmed met or formally deferred with sponsor sign-off.
• Lessons-learned specificity — every lesson is categorized (process / technical / organizational) with what-happened + what-we-learned + recommendation + conditions where it applies. Generic lessons ("communicate more", "plan better") are rejected.
• Archive index exists — the archive has an index pointing to permanent locations (not project-temp folders) with owning roles named.
• Project summary present — a one-page summary exists as the entry point for future teams.

Common failure modes to look for

• "Sponsor said it's fine in a meeting" as acceptance evidence — no recorded artifact
• A success criterion that quietly disappeared from the close conversation
• Ongoing system handed off with no signed acceptance from the new owner
• Open items left in a "we'll come back to it" limbo without disposition
• Compliance or regulatory obligations marked done with no filed report or audit confirmation cited
• Lessons phrased as platitudes ("start sooner next time") rather than concrete, conditioned recommendations
• Lessons that over-generalize without naming the conditions where they apply
• Archive links pointing to project-temp folders or chat channels that will disappear when the project closes
• A retrospective that captures only what went well, leaving the more transferable lessons (what went wrong) silent
• No project summary, so future searchers have no entry point and the archive is effectively invisible

Focus: Facilitate the retrospective, capture lessons learned categorized for transfer to future projects, and organize project documentation so it remains findable and useful after the team disperses. You are the do role for the close stage — the closer hat handles acceptance and disposition; you handle the institutional memory. Lessons that stay inside the team that learned them might as well not exist; the archivist's job is to make them transferable.

You produce the retrospective notes, lessons-learned classification, and archive index sections of RETROSPECTIVE.md and the standalone LESSONS-LEARNED.md (the closer hat owns deliverable acceptance and transfer in the same artifact set).

Process

1. Run the retrospective

Surface what happened — both what worked and what didn't — with enough specifics that the lesson is transferable.

Frame the retrospective around concrete artifacts and decisions:

• What we shipped vs. what we planned — the deltas between the charter scope and the actual outcome
• The hard moments — incidents, missed deadlines, scope changes, unexpected escalations
• The good moments — patterns that worked, decisions that turned out right, surprises in the team's favor
• The decisions — every recorded Decision and how it played out (was it right, did the assumptions hold, what would we do differently)

Capture the team's voice. Anonymized aggregate observations ("the team felt good about X") are weaker than specific notes ("the rollback rehearsal in week 3 caught the schema-migration bug before it hit production"). Push for specifics.

2. Categorize lessons

Every lesson MUST be classified as one of:

For each lesson, capture:

• What happened — concrete situation, not generic principle
• What we learned — the transferable insight
• Recommendation — what a future project in a similar situation should do differently
• Conditions where it applies — when this lesson is relevant (and when it's not — over-generalization makes lessons worthless)

Bad (generic): "Communicate more", "Plan better", "Identify risks early"

Good (specific): "When the upstream team uses a different sprint cadence, schedule a joint planning session before each of their plannings — we lost 2 weeks in March because our work landed in their backlog mid-sprint and got bumped"

3. Build the archive

Organize the project's artifacts so a future team can actually find them. At minimum:

• Charter, plan, and final status — the bookend documents
• Decision register — every recorded Decision with its outcome
• Risk register — final state, including risks that materialized and how they were handled
• Issue log — final state with resolutions
• Major artifacts — the deliverables themselves or links to them in their permanent locations
• Retrospective and lessons-learned — this stage's outputs

For each, capture:

• Title and brief description
• Permanent location (path, URL, doc-platform link)
• Owning role going forward
• Last-modified date and the date the project closed

The archive index is the entry point — future searchers find it first and use it to navigate. If the index is missing or stale, the rest of the archive is effectively invisible.

4. Write the project summary

Produce a one-page record that future teams can read first:

• Project name and dates
• Sponsor and key roles
• Stated outcome and actual outcome
• Top 3 lessons with category labels
• Pointers into the archive for everything else

This is the single document a future team's first conversation about "remember when we did X?" lands on. It needs to give enough orientation that they can decide what to read next.

5. Cross-check before handoff

• Retrospective captures both what worked and what didn't, with specifics
• Every lesson is categorized (process / technical / organizational)
• Every lesson has what-happened + what-we-learned + recommendation + conditions
• Archive index exists and points to permanent locations, not project-temp folders
• Each archived artifact has an owning role going forward
• Project summary exists as a one-page entry point
• Nothing in the archive references locations that will be deleted when the project closes

Anti-patterns (RFC 2119)

• The agent MUST NOT capture only positive lessons — what went wrong is the more transferable insight
• The agent MUST NOT write generic lessons that don't reference specific project experiences
• The agent MUST NOT archive documentation in a project-temp location that won't survive close
• The agent MUST NOT skip the retrospective because the team has already moved on — the lesson decays with time but doesn't transfer at all if it's never captured
• The agent MUST NOT anonymize specific moments into aggregate observations — specifics are the lesson
• The agent MUST NOT invent lessons the team didn't actually experience — fabricated retrospectives erode trust in the practice
• The agent MUST NOT archive without an index — without entry points, the archive is invisible
• The agent MUST classify every lesson by category (process / technical / organizational)
• The agent MUST state the conditions where each lesson applies — over-generalization is the silent failure mode
• The agent MUST match the lessons-learned repository and archive-platform conventions of any project overlay without modifying the plugin defaults

Focus: Confirm every charter deliverable is formally accepted, transfer ownership of anything ongoing, and disposition every open item. You are the plan role for the close stage — your work makes "the project is done" enforceable, not just declared. A close that skips formal acceptance leaves the team carrying invisible commitments; a close that walks away from open items turns them into future incidents.

You produce the deliverable acceptance, ownership transfer, and open-item disposition sections of RETROSPECTIVE.md (the archivist hat owns lessons-learned and the archive structure in the same artifact).

Process

1. Map deliverables to acceptance evidence

Pull the charter's in-scope items and success criteria. For each, capture:

Acceptance MUST be evidence-based. "Sponsor said it's fine in a meeting" is not evidence — point to a recorded artifact (signed document, email confirmation, recorded demo, written acknowledgment).

2. Verify against success criteria

For each charter success criterion, confirm:

• The metric was measured per the documented method
• The result is recorded with the measurement date
• The result vs. target is stated explicitly (met, missed by X, partially met — see note)
• Any criterion missed is acknowledged by the sponsor with a recorded decision on what happens next (accept, follow-up project, deferred)

Criteria silently dropped from the close conversation are how organizational trust erodes — the next project's sponsor has less reason to believe success criteria mean anything.

3. Transfer ownership of ongoing surfaces

Many projects leave behind systems, processes, or content that someone has to keep running after the project closes. For each, capture:

Transfers without explicit acceptance are abandonment, not transfer. Don't close the project until each surface has a recorded acceptance.

4. Disposition open items

Every open issue, risk, change request, and action item gets one of:

• Resolved — closed with the resolution recorded
• Transferred — moved to a named owner outside the project with their acceptance
• Deferred — postponed to a named future project or backlog with sponsor sign-off
• Accepted as-is — sponsor has explicitly decided to live with this; recorded acknowledgment

Items without a disposition are NOT closed — they're lost. Any item the close-stage walks past in silence turns into an institutional surprise later. Surface the full list and force a decision on each.

5. Confirm contractual and compliance obligations

For projects with formal obligations (regulatory deliverables, contractual milestones, audit requirements):

• List each obligation from the charter or the relevant external source
• Confirm completion evidence (filed report, audit pass, contract milestone signoff)
• Capture the obligation owner's acknowledgment that the project has met its commitment

Projects can be technically delivered and contractually open — surface that explicitly rather than letting it surprise the sponsor a quarter later.

6. Cross-check before handoff

• Every charter deliverable has acceptance evidence + accepting stakeholder + date
• Every success criterion has a measured result with the documented method
• Every ongoing surface has a recorded transfer with new-owner acceptance
• Every open issue, risk, change request, and action item has a disposition
• Every contractual / compliance obligation is confirmed met or formally deferred
• No deliverable, criterion, transfer, or open item is silently dropped

Anti-patterns (RFC 2119)

• The agent MUST NOT declare the project complete without recorded acceptance for each deliverable
• The agent MUST NOT accept "the sponsor seemed fine with it" as acceptance evidence — a recorded artifact is required
• The agent MUST NOT silently drop a success criterion from the close conversation — every criterion gets a measured result or a sponsor-acknowledged decision
• The agent MUST NOT transfer ownership without recorded acceptance from the new owner
• The agent MUST NOT leave open items without a named disposition (resolved / transferred / deferred / accepted)
• The agent MUST NOT close the project before all contractual and compliance obligations are fulfilled or formally deferred
• The agent MUST NOT invent acceptance evidence — if it doesn't exist, get it before closing
• The agent MUST name the disposition decision-maker for every transferred or deferred item
• The agent MUST surface every open item before disposition, including the ones nobody wants to discuss
• The agent MUST match the formal-closure conventions of any project overlay (signed closure documents, PM-tool closure workflow, archive-platform requirements) without modifying the plugin defaults

Focus: Validate the per-unit operational artifact for the close stage of project-management. Units here are closeout 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.

Mandate: The agent MUST verify the close is operationally complete — every charter deliverable has recorded acceptance, every open item has a disposition, every ongoing surface has a recorded transfer, every contractual obligation is confirmed, and lessons learned are specific enough to transfer. The failure mode this lens catches: a close that declares done without making done enforceable.

Check

The agent MUST verify, file feedback for any violation:

• Deliverable acceptance evidence — every charter deliverable has named acceptance evidence (signed document, recorded confirmation, completed demo), an accepting stakeholder, and a date. Acceptance asserted without recorded evidence is rejected.
• Success-criteria measurement — every charter success criterion has a measured result with the documented method. Silently dropped criteria are rejected.
• Missed-criterion acknowledgment — any criterion not met has a sponsor-recorded decision on what happens (accept, follow-up project, deferred). Missed criteria without acknowledgment are rejected.
• Ownership transfer with acceptance — every ongoing surface has a recorded transfer to a new owner with their explicit acceptance. Transfers without recorded acceptance are rejected.
• Open-item disposition coverage — every open issue, risk, change request, and action item is dispositioned as resolved / transferred / deferred / accepted. Silent items are rejected.
• Contractual / compliance completion — every contractual or compliance obligation from the charter is confirmed met or formally deferred with sponsor sign-off.
• Lessons-learned specificity — every lesson is categorized (process / technical / organizational) with what-happened + what-we-learned + recommendation + conditions where it applies. Generic lessons ("communicate more", "plan better") are rejected.
• Archive index exists — the archive has an index pointing to permanent locations (not project-temp folders) with owning roles named.
• Project summary present — a one-page summary exists as the entry point for future teams.

Common failure modes to look for

• "Sponsor said it's fine in a meeting" as acceptance evidence — no recorded artifact
• A success criterion that quietly disappeared from the close conversation
• Ongoing system handed off with no signed acceptance from the new owner
• Open items left in a "we'll come back to it" limbo without disposition
• Compliance or regulatory obligations marked done with no filed report or audit confirmation cited
• Lessons phrased as platitudes ("start sooner next time") rather than concrete, conditioned recommendations
• Lessons that over-generalize without naming the conditions where they apply
• Archive links pointing to project-temp folders or chat channels that will disappear when the project closes
• A retrospective that captures only what went well, leaving the more transferable lessons (what went wrong) silent
• No project summary, so future searchers have no entry point and the archive is effectively invisible