---
name: completeness-build
description: "Build a new or materially expanded resource or operational workflow in a data-heavy web app with an explicit completeness contract. Use when the user explicitly requests implementation of an admin, CRUD, directory, queue, or management feature, including requests that require a contract or approval stop before edits. Do not invoke when the requested deliverable is only a plan, or when the request is for marketing, e-commerce, editorial, styling-only work, an audit, a refactor-only task, a narrow bug fix, or a tiny fully specified change."
license: MIT
---

# Completeness Build

Implement the approved workflow completely within the user's scope.

## Boundaries

- Inspect before editing. Follow the repository's architecture, design system, authorization model, and validation patterns unless they conflict with correctness.
- Limit v0.1 to operational apps such as admin systems, CRMs, internal tools, and SaaS operations; do not apply it to marketing, e-commerce, or editorial product design.
- Do not silently add every plausible feature. Make applicable completeness decisions explicit.
- Keep contracts and reports in chat unless the user explicitly requests a file. Application-code edits are allowed only after the approval gate below.
- Do not treat UI hiding, a component import, or a successful happy path as proof of complete behavior.

## Load the right guidance

Read [the capability catalog](references/capability-catalog.md), [the evidence model](references/evidence-model.md), and [the approval and delivery contract](references/approval-and-delivery.md). If the project uses React, Next.js, shadcn/ui, TanStack Table, tRPC, or Prisma, also read [the React/Next implementation reference](references/react-next.md).

## Workflow

1. **Inspect the target.** Determine actors, resource lifecycle, data ownership, expected scale, permissions, consequential actions, test setup, and the closest sound project patterns. Give evidence-backed existing defects stable finding IDs and carry them into the contract.
2. **Establish the contract.** Reuse a supplied completeness plan or a user-confirmed audit handoff. Otherwise derive the minimum contextual contract from the catalog. Require positive evidence from the request, domain, or repository before a rule enters the contract. Omit unmet triggers instead of inventorying them as `defer` or `not-applicable`; record an exclusion only when it prevents a concrete likely scope mistake. Group related rules into the smallest useful product-level decisions. Use only `present`, `include`, `defer`, `not-applicable`, and `needs-decision`.
3. **Apply the approval gate.** Show the complete contract before the first project mutation. If the current request explicitly approves this exact plan, pre-authorizes recommended defaults, or asks to implement a previously confirmed audit selection, state the accepted contract briefly and continue without pausing. Otherwise ask once for approval and stop. The existence of an unapproved plan file is not approval.
4. **Refuse ambiguity.** Do not mutate while any item is `needs-decision`. An applicable `must` rule cannot be silently deferred; resolve the conflict or report the blocker.
5. **Implement only the approved contract.** Preserve `present` behavior, build `include` behavior, and do not smuggle in `defer` or `not-applicable` items. Keep collection behavior consistent with:

   `displayed rows = paginate(sort(filter(complete reachable dataset)))`

6. **Verify behavior.** Exercise happy paths, boundaries, empty/no-results/error states, authorization, consequential actions, and relevant accessibility behavior. Use the strongest existing automated checks. Browser verification is optional; label rendered claims `manual-review` when they were not checked in a browser or equivalent UI test.
7. **Report the delivery.** Summarize implemented contract items, changed behavior, tests and browser evidence, explicit deferrals, and remaining `manual-review` items. Do not claim completion when a critical approved item failed verification.

## Exit conditions

Finish only when every `include` item is implemented or clearly reported as blocked, verification results are named, and the final report contains no hidden scope additions. A later safety approval required by the environment does not count as a second completeness gate.