Holly Engineering

    Definition of Done (DoD)

    Purpose: the quality checklist a piece of work must pass before it's considered complete. This is the exit gate — the counterpart to Definition of Ready, which is the entry gate. If DoR answers "is this worth starting?", DoD answers "is this actually finished?"

    Status: draft for the 2026-07-07 Forum. This is meant to be ratified and edited, not obeyed. It describes how a small, fast-moving team should ship — not idealized ceremony. Trim what doesn't earn its place. (This is the one worked exemplar — the altitude the other chapters should aim for.)

    Done means merged and working, not "code written." A branch that passes review but breaks in QA isn't done. A feature that ships without its docs isn't done. "Done" is a single, shared bar so nobody has to guess what "finished" means.

    The checklist

    A change is done when all of these hold. Most are gated by CI or the pre-commit hooks already — the list just makes the bar explicit.

    Code & correctness

    • Meets the acceptance criteria from the ticket / PRD.
    • Typecheck passes (pnpm typecheck — tsgo, not tsc).
    • Lint passes (pnpm lint — oxlint).
    • Formatted (pnpm format:check — oxfmt).
    • Tests pass (pnpm test), and new behavior has tests covering it. Bug fixes include a regression test.
    • No dead code, no commented-out blocks, no stray console.log / TODO left as the actual fix.

    Review & merge

    • Opened as a PR — no direct commits to main.
    • Reviewed and approved by at least one other engineer.
    • Conventional Commit title; PR description says what changed and why.
    • AI-authored PRs state their goal up front — what the agent was asked to do and what it changed — so a reviewer can check intent against diff.
    • CI green on the PR (not just locally).

    Validation

    • Validated in QA before it counts as shipped — see Release & QA. Passing review is necessary, not sufficient.
    • Manually exercised the happy path at least once (or an automated test stands in for it).

    Docs & safety

    • Docs updated when behavior, an interface, or a runbook changed. If nothing changed, that's fine — but decide, don't skip by default.
    • No secrets, .env files, keys, or tokens committed.
    • Follows the Engineering Standards (coding, testing, branching, review).

    Not every change carries the whole list

    The bar scales with the blast radius. A one-line typo fix in a doc doesn't need a regression test; a change to auth or a shared package needs all of it and then some. Use judgment — the checklist is the ceiling for a normal feature, not a tax on trivial changes. When in doubt, apply more of it, not less.

    Open questions for the forum

    • How much QA gates "done"? Does every change need explicit QA sign-off, or only user-facing / risky ones? This depends on what Release & QA lands on.
    • Do we wire this into tooling? A PR template checklist and/or a CI check would make DoD enforced rather than remembered. Worth it, or ceremony?