Definition of Done

This checklist is a framework. Enable the sections that apply to the change. Explicitly document each section that does not apply.

These checks derive from the principles and profiles. They are not a second normative source. FOUNDATION.md permanently enables the profiles that the project must support. For each work unit, the delivery evidence selects only the profiles and sections whose trigger occurs.

Core

Checks derived from P02, P03, P04, P05, P07, P08, P09, P10, P17, P18, P19, P20, and P21.

• The result solves the requested problem. It does not implement an implicit extension.
• The current state, target, and limits are correctly identified.
• No fact, number, user, verification result, or production state is invented.
• The initial worktree was inspected, and unrelated changes were preserved.
• The diff has a focused scope, has been reviewed, and contains no secret.
• Structural decisions, including product decisions, and their trade-offs are documented in an ADR.
• CHANGELOG.md describes the delivered change and its observable effect.
• The canonical source and derived artifacts are aligned.
• The verify command passes in the applicable environment.
• compose.yaml exists at the root, and scripts/check_compose.py passes.
• The installation, execution, and verification documentation remains reproducible.
• All technical content is in English and follows P20.
• Verification limits are identified.

Documentation and content

Checks derived from P02, P03, P04, P10, P16, and P20.

• A normative concept is defined in one location only.
• Each maintained Markdown file is classified exactly once in documentation.json.
• The documentation catalog is current, and each file remains accessible.
• Its public, internal, reference, or archive visibility is correct.
• Links, anchors, navigation, and indexes are consistent.
• Facts and attributions have been verified.
• Editorial review checks the English language, sentences, terminology, jargon, and externally required terms defined by P20.
• Translations have structural and semantic parity if they exist.
• Dates are absolute.
• Archives, changelogs, and dated audits are not presented as the current state.
• The final rendering has been checked, not only the Markdown source.
• Nimbus adapter tests, type checking, build, and lint pass.
• The collection generated by Nimbus was not edited manually.
• A Nimbus publication exposes only explicitly authorized audiences.

Web interface or product

Checks derived from P10, P13, P14, and profiles/web.md.

• The primary user flow works on mobile and desktop.
• Supported themes or modes have been tested.
• Keyboard navigation is complete, and focus remains visible.
• ARIA states match the actual state.
• Contrast meets the defined level.
• Color is not the only means of conveying information.
• Touch targets have suitable dimensions.
• The interface respects prefers-reduced-motion.
• Loading, empty, error, success, and unavailable states are handled.
• There is no horizontal overflow or unexpected console error.
• Routes, metadata, canonical URLs, indexing, and sharing are correct if the interface is public.
• Performance budgets are met on a representative target.
• The published surface has been visually verified.

API, backend, and data

Checks derived from P10, P11, P13, P14, and profiles/backend-data.md.

• The canonical contract is updated before or with the implementation.
• Incompatible changes are detected and identified.
• Migrations are versioned and tested.
• A backup exists before each risky migration.
• Restoration or rollback has been tested on an isolated target.
• Sensitive operations are idempotent or protected against repeated execution.
• Authorization, tenant isolation, and access denial are tested.
• External errors, timeouts, retries, and duplicates are handled.
• Metrics contain no secret or unnecessary personal data.
• Health checks verify the actual service requirements.

Runtime logging

Checks derived from P02, P04, P10, P11, P14, P20, and P21. Enable this section when the project emits or changes first-party runtime log records.

• The canonical logging contract identifies the schema mapping, event-name source, production threshold, sinks, sampling, retention, audit applicability, and alert ownership.
• Representative log records at each severity that the project uses pass an automated schema check.
• Event names are stable and low-cardinality. Messages are short controlled-English explanations. Variable values use typed fields.
• Each applicable operation includes trace and span identifiers or another trusted correlation identifier.
• Each automated consumer selects a stable event name or field. It does not match message text.
• When a component can report a failed technical operation, a failure-path test produces one ERROR log record from the component that reports the final outcome and preserves the cause when an exception caused the failure.
• A synthetic sensitive value does not appear at any enabled level or in structured exception data.
• Tests cover untrusted values, log injection, exporter failure, and volume protection in proportion to risk.
• Audit and security records use their defined stream, access, integrity, retention, and failure controls. Runtime verbosity cannot disable or sample them.
• A project that emits no first-party runtime log records marks this section as not applicable.

Generated artifacts

Checks derived from P03, P04, P09, and P10.

• The editorial or technical source is identified.
• Generation is deterministic and scripted.
• The derived artifact was not edited manually.
• The source, derived artifact, and consumers are delivered together.
• Resource caches or versions were invalidated when necessary.
• The format, size, dimensions, transparency, and provenance were checked.

Infrastructure and production

Checks derived from P08, P10, P11, P14, P15, and profiles/infrastructure-production.md.

• The exact target of each destructive action was listed.
• A human checkpoint exists for access, secrets, purchases, and irreversible operations.
• Configuration was verified before reload or restart.
• Deployment uses an immutable artifact.
• Rollback is specific and does not depend on an uncertain rebuild.
• Permissions are minimal, and secrets are not displayed or versioned.
• Health, ports, routes, and dependencies were verified after deployment.
• Backups are off-site when the risk requires it.
• A representative restoration was demonstrated.
• External monitoring supplements monitoring that runs with the service.

Docker Compose and local environment

Checks derived from P09, P10, P13, and P19.

• compose.yaml contains all services and dependencies for integrated local execution.
• An optional host shortcut is not the only documented path.
• Each external image is pinned by digest. A locally built service has an explicit source and context.
• Each long-running service has a representative health check.
• Each finite command without a health check has the foundation.lifecycle=job label.
• python3 scripts/check_compose.py and docker compose config pass.
• docker compose up --build --wait reaches a healthy state for each project that has services.
• Useful URLs, ports, or paths are checked from the running environment.
• docker compose down stops the environment correctly and does not delete volumes by default.
• Each reset command identifies the exact data that it deletes.
• CI runs the same verify command and does not bypass the Compose check.

Experiment

Checks derived from P02, P08, P12, and profiles/experiment.md.

• The experiment has a name and is identified as an experiment.
• It does not silently replace the canonical surface.
• It is isolated from production data and secrets.
• Demonstration data is identified.
• Public indexing is disabled when necessary.
• The cost and review date are defined.
• A stop and removal procedure exists.
• The criteria for promotion to a product are documented.

Delivery and closure

Checks derived from P05, P08, P10, P14, P17, and P18.

• The commit contains only the work unit.
• Checks for the final SHA or artifact pass.
• Each completed work unit was committed after its applicable verification.
• The final SHA exists on the expected remote branch. Use the canonical branch if direct write access is permitted. Otherwise, use a dedicated branch.
• Available remote checks were observed. Each push blocker is exact and attributed, and a resumable local SHA exists.
• The required deployment succeeded when it was in the authorized scope.
• The final URL, service, or file was checked.
• Useful evidence is summarized.
• Remaining risks and external actions are separate from completed work.
• The canonical roadmap or backlog contains the actual next work.