# Feature Completeness — Gap Analysis Pass

A PRD FR list maps **1:1 to obvious Features**, but a system only works end-to-end when the **implicit Features** the FRs imply also exist. This pass derives them. Run it:
- in `/tas-master-plan` (after FR→Feature mapping, before building tracks),
- in `/tas-feature` CREATE (after inferring stacks, before presenting the Feature list),
- and **every time a Feature is added during maintenance** — so the same rules apply for the project's whole life, not just the first breakdown.

Implicit Features mostly fall out of the **SAD**, not the FR text. Read it first.

## Step 1 — Read SAD carefully (mandatory)

Grep SAD headings, then read the sections that spawn implicit work:
- **§10 Security** — auth/security flows imply Features: reset password, MFA enrolment, email verification, account lockout, audit-log viewer, consent.
- **§11 NFR Strategies** — each NFR becomes a per-Feature constraint (route to NFR, see Step 3), not a new Feature, unless it needs its own flow (e.g. a backup/restore admin screen).
- **§9 Integration & Data Flow** — async/external flows imply glue Features: webhook receiver, retry/dead-letter handling, reconciliation, token refresh.
- **§8 Data / ERD** — any entity without a full CRUD/lifecycle Feature is a gap. Seed/reference data, migration, import/export, archival.
- **§7 Module & Component** (per-container module + component tables; the `MOD-NN.C#` component list is the coverage unit) — the structural coverage anchor (see Step 1.5).

## Step 1.5 — Design-item coverage (holistic — `/tas-master-plan`)

Build the full **design inventory** from the SAD, then assert **every tracked design item is claimed by ≥1 Feature** (claims live in each Feature-Technical `## Modules` block; the as-built record is `architecture-map.yaml`). This is the structural anti-miss guarantee — functional lenses (Step 2) catch implied *behavior*; this catches designed *pieces* that no Feature builds.

Enumerate and check each tracked item type:

| Item | Source | Claimed via | If unclaimed → |
|------|--------|-------------|----------------|
| Component `MOD-NN.C#` | SAD §7 component tables | `Builds` | missing/extend Feature (`→ Feature`) |
| Entity `E-NNN` | SAD §8.1 Domain Model | `Entities (owns)` — exactly one owner | missing owner Feature (`→ Feature`) |
| Contract `IC-NN` | SAD §9.2 Registry | `Contracts (produces)` — one producer | missing producer Feature (`→ Feature`) |
| NFR `NFR-NNN` | SAD §11 | `NFRs` (≥1 Feature) or own Feature | route `→ NFR` (constraint) or `→ Feature` |
| Security `SEC-NN` | SAD §10 Controls | `Security` (≥1 Feature) or own Feature | route `→ NFR`/constraint or `→ Feature` |

- **Buildable** (component / entity / contract): each needs exactly one builder/owner/producer Feature. Unclaimed → a missing Feature (or a gap in an existing Feature's claim) → propose/extend (route `→ Feature`). Pure `infra` items may be owned by a scaffold Feature; confirm one owns it.
- **Cross-cutting** (NFR / security): each must be addressed by ≥1 Feature as a constraint, or become its own Feature (e.g. MFA, backup/restore screen). Unclaimed → attach to the relevant Feature (`→ NFR`/constraint) or spawn a Feature (`→ Feature`).
- A module is covered only when **all** its components are claimed.
- **Brownfield baseline:** items marked `origin: baseline` in `architecture-map.yaml` (pre-existing code seeded by `/tas-init`) are **already Covered — exclude them from the "must be claimed" check**. Only `origin: feature` items (greenfield + all new work) require a claiming Feature. A new Feature touching a baseline entity records it under `Entities (uses)`, not `owns`.

(In `/tas-feature` single-Feature mode, just record which items the new Feature claims — full-catalog coverage is the master-plan's job.)

## Step 2 — Run the functional lenses

For the FR set + SAD, ask each lens "what must also exist?". Conditional lenses only fire when the SAD/PRD says so.

1. **Lifecycle / CRUD symmetry** — every create has read/update/delete/list? start↔cancel, submit↔edit/withdraw, enable↔disable?
2. **Auth & access** — login→logout, reset pw, verify email, session expiry, lockout, MFA, role/permission enforcement on every protected action.
3. **Error & edge paths** — failure handling for each external call, empty states, validation errors, retry, idempotency, concurrency conflict.
4. **Notifications & feedback** — confirmation emails, status-change notifications, in-app alerts the flows imply.
5. **Data lifecycle** — seed/reference data, migration, import/export, archival, soft-delete, retention, audit trail.
6. **Search & discoverability** — search, filter, sort, pagination wherever lists exist.
7. **Onboarding & first-run** — setup wizard, sample/seed data, empty/initial states.
8. **Multi-tenancy & isolation** *(only if SAD is multi-tenant)* — tenant onboarding/offboarding, data partition, per-tenant config.
9. **i18n / l10n** *(only if PRD requires)* — language, timezone, currency, formatting, RTL.
10. **Admin, config & support tooling** — admin console, role management, feature flags, system config, impersonation/support view.
11. **Reporting & analytics** *(if PRD implies)* — dashboards, scheduled reports, export, event tracking.

## Step 3 — Route each candidate (anti-noise)

Not every candidate is a Feature. Route each one — this keeps the plan clean instead of spawning pseudo-Features for pure infra:

- **→ Feature** — has its own business flow + AC (e.g. reset password, tenant onboarding, export report). Create it.
- **→ NFR** — a property of an existing Feature, no standalone flow (e.g. caching, timeout, encryption, pagination limit). Add it to that Feature's `## NFR` section.
- **→ SAD** — reveals an architecture gap, not a Feature (e.g. missing DR strategy, no audit-log design). Flag it: "⚠️ Architecture gap — run `/tas-sad UPDATE`" and stop treating it as a Feature.

## Step 4 — Present for approval

Show candidates as a table — let the PE approve / reject / re-route, same as the scaffold proposal. Only approved `→ Feature` rows become Features.

```
Candidate Implicit Features (gap analysis):

| Candidate              | Lens            | Related FR | Route   | Why |
|------------------------|-----------------|------------|---------|-----|
| Reset password         | Auth & access   | FR-001     | Feature | login implies recovery |
| Response caching       | Performance     | FR-003     | NFR     | property of product API |
| DR / backup strategy   | Reliability     | —          | SAD     | not designed in SAD §11 |

Approve which as Features? (all / numbers / re-route)
```

Approved Features are assigned IDs and created by the calling command's normal Feature-creation steps.