# Business Spec Template

This is the output template for `/fluent-use-case-discover`. The wizard fills in each section from gathered requirements. Sections marked CONDITIONAL are included only when relevant.

---

## Template

```markdown
# Business Spec: [Feature Title]

**Status:** DRAFT | REVIEW | APPROVED
**Date:** YYYY-MM-DD
**Profile:** <FLUENT_PROFILE>
**Retailer:** <RETAILER_REF>
**Requested by:** [stakeholder or team]
**Completeness:** XX% ([Insufficient / Partial / Sufficient / Complete])

---

## 1. Problem Statement

[Business problem in plain language. What pain exists today? Why does this matter?]

## 2. Feature Summary

[One-sentence description of the feature]

**Type:** [New capability / Enhancement / Bug fix / External integration / Data migration / Process change]
**Success Metrics:**
- [KPI 1 — e.g., "Reduce order fulfilment time from 4h to 1h"]
- [KPI 2 — e.g., "Eliminate manual carrier selection for 90% of orders"]

## 3. Scope

**In scope:**
- [Bullet list — what this feature will do]

**Out of scope:**
- [Bullet list — what this feature will NOT do]

## 3a. Existing State (conditional — include when extending an existing feature)

> Include this section when the feature extends, modifies, or builds on an existing Fluent Commerce feature. Skip for greenfield features.

If an architecture document exists at `features/<parent-slug>/architecture.md` (produced by `/fluent-feature-explain`), reference it here.

### Current Architecture Reference
- **Parent feature:** `<parent-slug>`
- **Architecture doc:** `features/<parent-slug>/architecture.md`
- **basedOn field in status.json:** `"basedOn": "<parent-slug>"`

### What Exists Today
| Artifact | Current State | To Be Modified? |
|----------|--------------|-----------------|
| Workflow `ORDER::HD` | v1.56, 14 rulesets | Yes — adding new ruleset |
| Rule `CreateFulfilment` | OOTB, no customization | Yes — replacing with custom |
| Settings `FULFILMENT_SPLIT_*` | Not present | New — to be created |

### What This Feature Changes
Describe the delta from current state. What's being added, modified, or removed? This section bridges the gap between the architecture doc (what IS) and the spec (what SHOULD BE).

## 4. Actors & Triggers

| Actor | Type | Module | Role in Feature |
|-------|------|--------|-----------------|
| [e.g., Store associate] | Human | Store App | Picks and packs items |
| [e.g., WMS] | System | External | Receives fulfilment requests via webhook |
| [e.g., Scheduled job] | Automated | Backend | Runs daily reconciliation |

**Trigger:** [What starts this feature — e.g., "New HD order placed via API"]

**Scope:** [Retailer-specific / Account-wide]

## 4a. Roles & Permissions

> CONDITIONAL: Include when human actors are involved and the feature has role-differentiated behavior or access restrictions. Skip for pure backend/automated features with no role considerations.

| Role | Type | Existing/New | Capabilities in this Feature |
|------|------|-------------|------------------------------|
| [e.g., ADMIN] | Platform (OOTB) | Existing | Can approve returns, view all retailers |
| [e.g., STORE_ASSISTANT] | Platform (OOTB) | Existing | Can process returns at their location only |
| [e.g., RETURNS_APPROVER] | Custom (label-only) | New | Approves returns over $500 — checked in rule code |

**Permission enforcement model:**
- [ ] Platform permissions only (Transition API filters by user's permissions)
- [ ] Custom role-check in rules (label-only roles, `me.roles` query in Java)
- [ ] Manifest visibility (`hasRole` helper, client-side only)
- [ ] Combination: [describe which layer handles what]

**Context scoping:** [How context affects this feature — e.g., "Store app users see only their location's returns (AGENT context). OMS users see all returns (RETAILER context)."]

**`actionedBy` needed?** [Yes/No — if yes, rules need to know the clicking user's identity for role-based logic]

## 5. Use Cases

### UC-01: [Happy Path Title]

**Actors:** [list]
**Preconditions:** [what must be true before this scenario starts]
**Flow:**
1. [Step 1 — e.g., "Customer places an HD order via the storefront"]
2. [Step 2 — e.g., "Order is created in Fluent with status CREATED"]
3. [Step 3 — ...]
...

**Postconditions:** [end state — e.g., "Order reaches COMPLETE, customer receives delivery confirmation"]

**Acceptance Criteria:**
- Given [precondition], When [action], Then [expected result]
- Given [precondition], When [action], Then [expected result]

### UC-02: [Alternative Path Title]

**Actors:** [list]
**Preconditions:** [what must be true]
**Branching condition:** [what makes this path different from UC-01]
**Flow:**
1. [...]
...

**Postconditions:** [end state]

**Acceptance Criteria:**
- Given [...], When [...], Then [...]

### UC-03: [Exception Path Title]

**Actors:** [list]
**Preconditions:** [what must be true]
**Trigger:** [what goes wrong — e.g., "Stock unavailable at allocated location"]
**Flow:**
1. [Error handling steps]
...

**Postconditions:** [recovery state or failure state]

**Acceptance Criteria:**
- Given [...], When [...], Then [...]

<!-- Add more use cases as needed: UC-04, UC-05, etc. -->

## 5a. User Journey Diagrams

> High-level visual flows showing WHO does WHAT and WHEN. These are business-focused — no workflow states, rulesets, or technical implementation details. The goal is to validate understanding of the feature with stakeholders before diving into technical planning.
>
> **Diagram validation:** All Mermaid blocks must pass `knowledge/mermaid-syntax-rules.md` rules before writing to the spec file.

### Actor Map

| Actor | Type | Interacts Via | Primary Actions |
|-------|------|---------------|-----------------|
| [e.g., Customer] | Human | Storefront / App | Places order, selects pickup |
| [e.g., Store associate] | Human | Store App | Picks items, confirms ready |
| [e.g., Fluent system] | Automated | Backend | Validates, routes, notifies |
| [e.g., WMS] | External system | Webhook | Receives fulfilment requests |

> Actors MUST match §4 exactly. If an actor appears in §4 but not here, either add them or note why they're excluded from the diagram.

### User Journey Flow

> Mermaid `flowchart TD` showing the end-to-end feature flow from the actors' perspective.
> Use subgraphs to group by actor or swim-lane. Decisions as rhombus nodes. Start/end as stadium-shaped nodes.
> **REQUIRED** when the feature has 2+ actors OR 2+ use cases (applies to most features).

```mermaid
flowchart TD
    subgraph Customer
        A([Order placed]) --> B{Pickup or Delivery?}
        B -->|Pickup| C[Select store & time slot]
        B -->|Delivery| D[Confirm delivery address]
    end

    subgraph System [Fluent Platform]
        C --> E[Validate stock at store]
        D --> F[Allocate to warehouse]
        E --> G{Stock available?}
        G -->|Yes| H[Reserve stock & notify store]
        G -->|No| I[Suggest alternative store]
        I --> C
    end

    subgraph Store [Store Associate]
        H --> J[Pick items from shelf]
        J --> K[Confirm ready for pickup]
    end

    K --> L([Customer collects order])
```

> **Coverage rule:** Every use case from §5 MUST be traceable in this diagram. Annotate branches with UC references (e.g., `-->|UC-02| ...`) when the diagram covers multiple paths.

### Actor Interaction Sequence (CONDITIONAL — include when 3+ actors collaborate or handoffs are complex)

> Mermaid `sequenceDiagram` showing the timeline of handoffs between actors.
> Best for features where the ORDER of interactions matters (e.g., "store associate must confirm BEFORE customer is notified").

```mermaid
sequenceDiagram
    actor C as Customer
    participant S as Storefront
    participant F as Fluent Platform
    actor SA as Store Associate
    participant EXT as Carrier

    C->>S: Place order (pickup)
    S->>F: Create order
    F->>F: Validate & route to store
    F-->>SA: Notify: new pickup order
    SA->>F: Confirm pick complete
    F-->>C: Notify: ready for pickup
    C->>SA: Arrive at store
    SA->>F: Confirm handover
    F->>F: Complete order
```

### Decision Flow (CONDITIONAL — include when 3+ branching conditions exist in business rules)

> Mermaid `flowchart TD` showing the decision tree for complex business logic.
> Aligns with §7 Business Rules — each decision diamond should reference a BR-XX rule.

```mermaid
flowchart TD
    A[New Order Received] --> B{Order type?}
    B -->|HD| C{Weight > 30kg? BR-03}
    C -->|Yes| D[Route to freight carrier]
    C -->|No| E{Express requested?}
    E -->|Yes| F[Route to express carrier]
    E -->|No| G[Route to standard carrier]
    B -->|CC| H{Stock at selected store? BR-01}
    H -->|Yes| I[Reserve at store]
    H -->|No| J[Check nearby stores]
    J --> K{Alternative found?}
    K -->|Yes| I
    K -->|No| L["Notify customer, out of stock"]
```

### Diagram Abstraction Rules

- **Business language only** — use "Order placed", "Pick items", "Notify customer" — NOT "CREATED status", "SendEvent rule", "GraphQL mutation"
- **Actors match §4** — use the same actor names; every actor from §4 should appear in at least one diagram
- **Use cases covered** — every UC from §5 should be traceable in at least one diagram
- **Decisions match business rules** — branching conditions should align with §7 Business Rules (reference BR-XX IDs)
- **Keep it high-level** — aim for 5–15 nodes per diagram. If more complex, split into sub-diagrams per use case
- **No technical details** — these diagrams feed into the plan's technical architecture (§3) where implementation specifics are added

<!-- CONDITIONAL: §5a is auto-generated from Phase 2-5 answers. Skip ONLY for single-actor, single-use-case, no-branching features (rare). -->

## 6. Entity Model

| Entity | Subtype | New/Existing | Orchestrable? | Workflow Status | Key Attributes | Notes |
|--------|---------|--------------|---------------|-----------------|----------------|-------|
| [e.g., Order] | HD | Existing | Yes | Rubix-enabled (v12, 14 rulesets) | deliveryWindow (new attr) | Needs new attribute for scheduling |
| [e.g., Fulfilment] | HD_WH | Existing | Yes | Rubix-enabled (v8, 10 rulesets) | carrierRef (existing) | No changes |
| [e.g., Fulfilment] | CC_STORE | New | Yes | New workflow needed | pickupCode (new attr) | New subtype for curbside |
| [e.g., Wave] | PICK_WAVE | Existing | Yes | Exists but NOT Rubix-enabled (0 rulesets) | — | Workflow needs rulesets added |
| [e.g., Customer] | — | Existing | **No** | N/A (not orchestrable) | loyaltyTier (existing) | Read-only reference, no workflow |

<!-- Orchestrable? column values:
     - Yes: entity type can have Rubix workflows and status transitions
     - No: entity type CANNOT have workflows (e.g., CUSTOMER, USER, SETTING)

     Workflow Status column values:
     - Rubix-enabled (vN, M rulesets): active workflow with configured rulesets
     - Exists but NOT Rubix-enabled: workflow definition exists but has no rulesets/transitions
     - New workflow needed: no workflow exists, must be created
     - N/A: entity is not orchestrable

     This validation is performed in Phase 4 (Layer 1-3 checks). Non-orchestrable entities
     referenced for workflow processing will block spec approval. -->

**Entity Relationships:**
[How entities connect in this feature. Example:]
- Order (HD) creates 1..N Fulfilments (HD_WH or CC_STORE)
- Fulfilment completion triggers Order status update via cross-entity event
- Location is referenced by Fulfilment for pick/pack assignment

## 7. Business Rules

| # | Rule Name | Condition | Action | Applies To | Time-Based? |
|---|-----------|-----------|--------|------------|-------------|
| BR-01 | [e.g., Stock validation] | If requested qty > available qty | Reject or split | UC-01, UC-02 | No |
| BR-02 | [e.g., Auto-cancel] | If no pick action within 4 hours | Cancel fulfilment, notify ops | UC-03 | Yes (4h) |
| BR-03 | [e.g., Carrier routing] | If weight > 30kg | Route to freight carrier | UC-01 | No |

<!-- CONDITIONAL: Only include if Phase 5 was asked -->

## 8. Integrations

| System | Direction | Method | Data Exchanged | Failure Handling |
|--------|-----------|--------|----------------|------------------|
| [e.g., WMS] | Fluent → External | Webhook | Fulfilment details (items, qty, location) | Retry 3x (5min interval), then alert ops |
| [e.g., Carrier API] | Fluent → External | REST API | Shipment request (weight, address, SLA) | Queue for manual retry |
| [e.g., POS] | External → Fluent | Webhook | Order creation payload | Validate payload, reject malformed |

<!-- CONDITIONAL: Only include if Phase 6 was asked -->

## 9. User Actions

| Action Label | Actor | Available At Status | Form Fields | Confirmation? | Bulk? |
|-------------|-------|---------------------|-------------|---------------|-------|
| [e.g., Confirm Pick] | Store associate | PICKING | qty_picked (number, required) | No | No |
| [e.g., Cancel Order] | Admin | CREATED, BOOKED | reason (dropdown, required) | Yes | Yes |
| [e.g., Force Complete] | Admin | any except COMPLETE | notes (text, optional) | Yes | No |

<!-- CONDITIONAL: Only include if Phase 7 Part A was asked -->

## 9a. UI / Frontend Requirements

> CONDITIONAL: Include when the feature has visible UI impact — new pages, modified layouts, new columns/cards/tabs, navigation changes. Skip for pure backend features.

> **Link to Entity Model (§6):** Each page should reference the entity types it displays from §6. The Data Requirements table below captures the GraphQL queries needed to fetch that data. This section feeds directly into Plan Section 10 (UI / Manifest Artifacts).

### Pages & Views

| Page / View | App | Type | Description |
|-------------|-----|------|-------------|
| [e.g., Appeasement list] | OMS | NEW | List all credit memos of type APPEASEMENT with amount, status, linked order |
| [e.g., Order detail — tracking tab] | OMS | MODIFIED | Add shipment tracking card to existing order detail tabs |

### Information Display

**List pages:**
| Page | Columns | Filters | Search | Sort |
|------|---------|---------|--------|------|
| [e.g., Appeasement list] | Ref, Order Ref, Amount, Status, Created | Status, Date range | By ref or order ref | Created date desc |

**Detail pages:**
| Page | Cards / Sections | Data Shown | Conditional? |
|------|-----------------|------------|--------------|
| [e.g., Appeasement detail] | Summary card, Line items table, Linked order card, Activity timeline | Amount, currency, reason, items with qty and price | Line items only when items exist |

### Navigation

| Entry Point | Location | Type |
|-------------|----------|------|
| [e.g., "Appeasements" sidebar link] | OMS main sidebar, under Orders section | NEW sidebar entry |
| [e.g., "View Appeasement" link on order detail] | Order detail page, appeasements tab | NEW tab |

### Data Requirements

| Page / View | Entity Type(s) | GraphQL Root Query | Key Fields Needed | Pagination? |
|-------------|---------------|-------------------|-------------------|-------------|
| [e.g., Appeasement list] | CREDIT_MEMO | creditMemos(first, status, type) | id, ref, status, totalAmount, currency, createdOn, order.ref | Yes |
| [e.g., Appeasement detail] | CREDIT_MEMO, ORDER | creditMemoById(id) | All fields + items connection + linked order summary | No (single entity) |

### Role & Permission Restrictions

| Page / View | Allowed Roles | Restricted Actions | Notes |
|-------------|--------------|-------------------|-------|
| [e.g., Appeasement list] | ADMIN, OPERATOR | — | All roles with OMS access can view |
| [e.g., Create appeasement action] | ADMIN only | OPERATOR cannot initiate | Role enforced at user action level |

### Entity-to-Page Mapping

| Entity Type | Subtype | List Page | Detail Page | Related Pages |
|-------------|---------|-----------|-------------|---------------|
| [e.g., CREDIT_MEMO] | APPEASEMENT | Appeasement list | Appeasement detail | Order detail (appeasements tab) |
| [e.g., ORDER] | HD | — (existing) | Order detail (modified — new tab) | Appeasement detail (back-link) |

### Component Approach

- [ ] Standard OOTB components sufficient (fc.list, fc.card, fc.tabs, etc.)
- [ ] Custom SDK component needed: [describe what and why]
- [ ] Not yet determined — needs `/fluent-mystique-analyze` assessment

### Custom Template Helpers

> CONDITIONAL: Include when the feature needs custom data formatting beyond the 50+ built-in Handlebars helpers (currency, dateFormat, eq, i18n, etc.). Skip when built-in helpers suffice.

| Helper Name | Purpose | Example Usage | SDK Required? |
|-------------|---------|---------------|---------------|
| [e.g., formatWeight] | Format weight with unit suffix | `{{formatWeight node.weight 'kg'}}` | Yes — TemplateRegistry |
| [e.g., statusColor] | Map status to display color | `{{statusColor node.status}}` | Yes — TemplateRegistry |

If no custom helpers are needed, state: "Built-in Handlebars helpers sufficient — no custom TemplateRegistry work needed."

**Decision guide:** Use a custom helper when you need to transform a data value for display (formatting, mapping, calculation) but don't need React hooks, state, or layout. If you need interactive UI or layout — that's a custom component, not a helper.

### Visual Mocks

> CONDITIONAL: Include when live DOM injection mocks were produced via `/fluent-mystique-preview` or `/fluent-ui-record`. Embed before/after screenshots showing the proposed UI change on the real app. Skip if no mocks were generated.

**Before** — [describe current page state]:

![Before](assets/before.png)

**After** — [describe what was added/changed]:

![After](assets/after.png)

> [How the mock was produced — e.g., "Live DOM injection on OMS order detail page, order REF_123"]

### UX Notes

[Any specific layout, responsive, accessibility, or interaction requirements. "None" if standard.]

<!-- CONDITIONAL: Only include if Phase 7 Part B was asked -->

## 10. Constraints & Risks

| # | Type | Description | Impact | Mitigation |
|---|------|-------------|--------|------------|
| R-01 | Risk | [e.g., WMS downtime during peak hours] | Fulfilments delayed | Queue + retry with alerting |
| R-02 | Risk | [e.g., New subtype may conflict with existing HD rules] | Regression | E2E test before deploy |
| C-01 | Constraint | [e.g., Must not break existing HD flow] | Regression | Test existing flow after changes |
| C-02 | Constraint | [e.g., Must handle 500 orders/hour at peak] | Performance | Load test before go-live |

**Volume expectations:** [e.g., "~200 orders/day normal, ~500/day peak (Black Friday)"]

## 11. Assumptions

- [A-01] [e.g., Existing inventory catalogue has accurate stock levels]
- [A-02] [e.g., WMS webhook endpoint is already deployed and accepts JSON]
- [A-03] [e.g., Store associates have Store App access configured]
...

**Important:** Assumptions become risks if proven wrong. Each should be validated during the feature plan phase.

## 12. Open Questions

- [Q-01] [e.g., What is the SLA for WMS response time?] — **Blocks:** BR-02 (auto-cancel timing)
- [Q-02] [e.g., Should partial picks be allowed or must the full qty be picked?] — **Blocks:** UC-02 definition
- [Q-03] [e.g., Which carrier API version are we targeting?] — **Blocks:** Integration design
...

**Important:** Open questions MUST be resolved before the feature plan can be completed. Each question notes which spec section it blocks.

## 13. Acceptance Criteria Summary

| UC | Criteria | Priority |
|----|----------|----------|
| UC-01 | Given stock available at warehouse, When HD order placed, Then fulfilment created and assigned within 30s | Must-have |
| UC-02 | Given partial stock across locations, When HD order placed, Then order split into multiple fulfilments | Must-have |
| UC-03 | Given no stock available, When HD order placed, Then customer notified and order moved to BACKORDER | Must-have |
| UC-01 | Given fulfilment shipped, When carrier confirms delivery, Then order status updated to COMPLETE | Must-have |
| UC-01 | Given peak load (500 orders/hour), When orders placed, Then all processed within 60s | Nice-to-have |

---

## Traceability Matrix

| Use Case | Entities | Business Rules | Roles | Integrations | User Actions | UI/Frontend | Diagram(s) |
|----------|----------|----------------|-------|--------------|--------------|-------------|-------------|
| UC-01 | Order (HD), Fulfilment (HD_WH) | BR-01, BR-03 | STORE_ASSISTANT | WMS, Carrier | Confirm Pick | Order detail, Fulfilment list | Journey Flow, Actor Sequence |
| UC-02 | Order (HD), Fulfilment x2 | BR-01 | STORE_ASSISTANT | WMS | Confirm Pick | — | Journey Flow (branch) |
| UC-03 | Order (HD) | BR-02 | — (automated) | Notification | — | — | Decision Flow |

This matrix ensures every use case traces through to entities, rules, roles, integrations, actions, UI requirements, and diagrams. Gaps in this table indicate incomplete requirements. The Roles, UI/Frontend, and Diagram(s) columns are optional — use "—" for use cases with no role differentiation, no UI impact, or no dedicated diagram.

---

## Deliberation Log

> Auto-generated by the self-critique protocol (Phase 10b). Shows what was reviewed, what was changed, and why.
> See `CRITIQUE_PROTOCOL.md` for the full protocol, rubric, and guardrails.

### Round 1

| # | Severity | Finding | Evidence | Verdict | Action |
|---|----------|---------|----------|---------|--------|
| C1 | [CRITICAL/HIGH/MEDIUM/LOW] | [Finding text] | [Evidence] | [ACCEPTED/REJECTED/DEFERRED] | [Action taken or rejection reason] |

<!-- Additional rounds if needed -->

### Summary
- **Rounds:** N (exit: [clean pass / converged / max reached])
- **Findings:** X total — Y accepted, Z rejected, W deferred
- **Spec changes:** [list of accepted changes applied]

---

## Recommendation

[Auto-generated by the wizard based on completeness score:]

**Score: XX% — [Insufficient / Partial / Sufficient / Complete]**

[One of:]
- "This spec is **ready for technical planning**. Run `/fluent-feature-plan` to produce the implementation plan."
- "This spec is **sufficient but has gaps** in [Phase X, Phase Y]. The feature plan can proceed but will make assumptions for those sections. Consider resolving open questions Q-01 and Q-02 first."
- "This spec has **too many gaps** to produce a reliable feature plan. Address: [list of missing phases]. Focus on [highest-priority gap]."

## Next Step

When this spec is APPROVED, proceed to technical implementation planning:

```
/fluent-feature-plan --feature <slug>
```
```

---

## Section Applicability Guide

| Section | Always? | When to Include |
|---------|---------|-----------------|
| §1 Problem Statement | YES | Every spec |
| §2 Feature Summary | YES | Every spec |
| §3 Scope | YES | Every spec |
| §4 Actors & Triggers | YES | Every spec |
| §4a Roles & Permissions | CONDITIONAL | When human actors are involved and feature has role-differentiated behavior or access restrictions |
| §5 Use Cases | YES | Every spec (minimum: happy path + 1 exception) |
| §5a User Journey Diagrams | CONDITIONAL | When 2+ actors OR 2+ use cases (most features). Auto-generated from §4 + §5 + §7 |
| §6 Entity Model | YES | Every Fluent feature |
| §7 Business Rules | CONDITIONAL | When there are decision points, validations, or calculations |
| §8 Integrations | CONDITIONAL | When external systems are involved |
| §9 User Actions | CONDITIONAL | When human actors interact via Fluent UI |
| §9a UI / Frontend Requirements | CONDITIONAL | When the feature has visible UI impact — new pages, modified layouts, navigation changes |
| §10 Constraints & Risks | YES | Every spec (even if brief) |
| §11 Assumptions | YES | Every spec |
| §12 Open Questions | YES | Every spec (can be empty if fully resolved) |
| §13 Acceptance Criteria | YES | Every spec |
| Traceability Matrix | YES | Every spec |

## Completeness Scoring Rubric

| Phase | Weight | Full Score | Half Score | Zero |
|-------|--------|------------|------------|------|
| 1. Feature Identity | 15% | All REQUIRED questions answered | Problem + summary but no metrics | Missing problem statement |
| 2. Actors & Triggers | 10% | Actors + trigger + scope identified | Trigger only, no actors | Neither identified |
| 3. Use Cases | 15% | Happy path + alternative + exception | Happy path only | No use cases defined |
| 3b. User Journey Diagrams | 5% | Actor map + journey flow + sequence/decision (if applicable) | Journey flow only, no actor map | No diagrams. N/A → 0% weight redistributed (single-actor, single-UC, no-branching) |
| 4. Entities & Data | 15% | All entities with subtypes + attributes + orchestrability validated + workflow status confirmed | Entities listed, no orchestrability check | No entities identified |
| 5. Business Rules | 15% | Rules per decision point in use cases | Some rules, gaps in coverage | N/A → 0% weight redistributed |
| 6. Integrations | 5% | All systems with method + failure handling | Systems listed, no details | N/A → 0% weight redistributed |
| 7a. UI Actions | 3% | Actions per actor with status + fields | Actions listed, no details | N/A → 0% weight redistributed |
| 7b. UI/Frontend Layout | 2% | Pages + display + nav documented | Pages listed, no details | N/A → 0% weight redistributed |
| 8. Constraints | 5% | Risks + assumptions + volume documented | At least one risk or assumption | Nothing documented |
| 9. Acceptance Criteria | 10% | Given/When/Then per use case + priority | Some criteria, not per UC | No acceptance criteria |

**When N/A phases exist:** Their weight is redistributed proportionally across applicable phases. A backend-only feature with no integrations redistributes 10% (Phase 6 + 7) across the remaining phases.

**Score interpretation:**
- **90-100%:** Complete — comprehensive, minimal assumptions needed
- **75-89%:** Sufficient — ready for feature plan, minor gaps flagged
- **50-74%:** Partial — can proceed but assumption-heavy
- **< 50%:** Insufficient — too many gaps to produce reliable plan
