# Business Completeness — Gap Analysis Pass (BRD / PRD)

A BRD/PRD is checked two ways before approval. `coverage-auditor` already verifies
**traceability** (every BR has an FR, every FR traces to a BR, …) — but traceability
**passes vacuously when an entire category of requirement is never written down**: if no
one ever mentions "who manages users", there is no missing link to detect. This pass
closes that hole.

It is the business-tier twin of `architecture-completeness.md` (SAD) and
`feature-completeness.md` (Feature planning). Same principle: walk a fixed set of lenses
and **give every lens an explicit disposition — never leave one silently absent.**

Run it:
- in `/tas-brd` CREATE (after drafting, before the coverage gate) and UPDATE (changed areas),
- in `/tas-prd` CREATE (after drafting, before the coverage gate) and UPDATE,
- record the outcome in the artifact's `## Completeness Disposition` table so the gate can verify it.

## The discipline (this is what makes it robust)

For each lens below, the author records ONE of:
- **Covered** — name the `AT/BF/BR/BRU` (BRD) or `Persona/FR/Module/NFR` (PRD) that addresses it.
- **N/A — {reason}** — a one-line reason it genuinely does not apply to this product.

A lens left blank is a **gap**, not a pass. This converts silent omission (the failure mode
that shipped the admin gap) into a visible decision. An LLM lens list is heuristic and will
never be exhaustive — the *N/A-with-reason* discipline, not the list, is the real safeguard.

## Lenses

Phrase each at the level of the artifact (BRD = actors/flows/rules/objectives; PRD = personas/FRs/modules).

1. **Actor & role coverage** — for every entity and flow: who *creates* it, who *operates/administers* it, who *owns* it? Is there an administrator/operator/approver role, or is one assumed but never named? (An entity called "managed" with no actor managing it is a gap.)
2. **Entity lifecycle (business CRUD)** — every core entity: is there a create / read / update / retire-disable path, and an ownership-assignment path where ownership matters? A spec that only *updates* an entity but never says who *creates* or *assigns* it is a gap.
3. **Identity & access governance** — account provisioning (create/enable/disable), role & permission assignment (grant/elevate/demote/revoke) and who performs them; login/logout, session expiry, lockout, reset where relevant.
4. **Data confidentiality & scope** — who may see what; scope boundaries; no lateral access. (Often already a BRU — confirm it exists.)
5. **Notifications & feedback** — status-change notifications, confirmations, alerts the flows imply.
6. **Exception & edge paths (business)** — what the business expects when an external/AI dependency fails, data is missing, or two actors act concurrently.
7. **Data lifecycle** — seed/reference data, import/export, archival/retention, audit trail of who-changed-what.
8. **i18n / l10n** *(only if the product needs it)* — language, timezone, currency, formatting.
9. **Reporting & analytics** *(only if implied)* — dashboards, aggregates, exports.
10. **Onboarding & first-run / bootstrap** — how the first users/roles/data come to exist (e.g. who creates the first Admin); initial/empty states.

Lenses 8–9 are conditional; the rest apply to almost every system. Tune per project, but do
not delete a lens silently — mark it `N/A — reason`.

## Present candidates for approval

Show gaps as a table; the PE approves / rejects / re-routes each — same UX as
`feature-completeness.md` Step 4. Only approved rows are written into the artifact.

```
Business completeness — candidate gaps:

| Candidate                | Lens                  | Route (BRD)      | Why |
|--------------------------|-----------------------|------------------|-----|
| Admin actor + user mgmt  | Identity governance   | Actor + BF + BR  | E-006 "managed" but no actor manages it |
| Create / assign Deal     | Entity lifecycle      | BF + BR          | flow updates a deal but never creates/assigns one |
| Bootstrap first Admin    | Onboarding/first-run  | Assumption       | who creates the first Admin? |

Approve which? (all / numbers / N/A + reason)
```

- **BRD routes:** Actor (`AT-NNN`), Business Flow (`BF-NNN`), Business Rule (`BRU-NNN`), Business Requirement (`BR-NNN`), or Assumption.
- **PRD routes:** Persona, User Flow, Functional Requirement (`FR-NNN`), Module (`MOD-NN`), or NFR.
- **PRD guard:** a product-tier gap that is really a *business* gap (a missing actor/objective) routes **back to the BRD** (`⚠ BRD gap → run /tas-brd UPDATE`) — never invent business analysis in the PRD.

## Record the disposition

Write the outcome into the artifact's `## Completeness Disposition` table (added to the BRD
and PRD templates). Every lens = one row. The `coverage-auditor` BRD/PRD gate reads this
table: a lens missing or blank is a completeness miss — ⚠ warn while `draft`, hard-block at
`approved`. The auditor enforces *that a disposition exists*, not whether an N/A reason is
correct (that stays the PE's call).
