The Definition of Done

"Worked on" is not "done." Stage 6 (review) settles the difference with a machine-checkable gate: the Definition of Done, the operational form of the floor's own "Definition of done." A Request advances review -> done only when DoD == 100% and a CODEOWNER approves. The canonical checklist is definition-of-done.md.

What DoD == 100% means

The DoD is scoped by request type. Every Request runs the Core items; classification flags add conditional items on top:

• Core (every Request) - code review complete, tests green, evals green for any agent-behavior change, the docs-required gate satisfied, signed Conventional Commits, English only, least privilege honored, no unapproved mutation, no secrets, links complete, evidence recorded.
• Conditional (added by flags) - impact.breaking adds migration notes; impact.security adds a threat model; type: deps adds a dependency review; a design-class change requires its RFC/ADR already Accepted.

Each item is pass, fail, n/a, or waived. DoD == 100% means no item is fail, every applicable item is pass, and every waiver is recorded.

Two gates, not one

The DoD score is the machine gate. The CODEOWNER approval is a separate human gate, computed independently. Both are required - this is separation of duties: propose is not approve.

The get_dod tool returns the checklist as data, so the gate is queryable rather than a matter of opinion. Its result is done only when no item fails, every applicable item passes or is validly waived, and codeownerApproval.approved is true. A perfect automated score with no human approval is not done.

Closing the loop

The final stage (done / doc-update) closes it: draft the Keep a Changelog entry from the Conventional commits, sync docs/, reindex the UID graph, and write a completion-evidence token to Core. Only when doc-drift is clear and that evidence is recorded does the Request reach done.