cfsa-antigravity 2.1.0 → 2.2.1

package/template/.agent/skills/pipeline-rubrics/references/ia-rubric.md

@@ -2,7 +2,7 @@
 
 | # | Dimension | ✅ (must meet ALL criteria) | ⚠️ | ❌ |
 |---|---|---|---|---|
-| 1 | Feature Enumeration | (a) Every feature from the ideation index's Must Have list appears in at least one shard. (b) Every feature has a clear scope boundary (what's in, what's out). (c) Every shard's `## Features` section contains Level-1 sub-features from the ideation domain files — not architecture headlines — and every sub-feature is represented in at least one section body (User Interactions, Data Model, Access Control, or Edge Cases). | Some features vague, scope unclear, or sub-features listed in `## Features` but not represented in any section body | Major Must Have features missing, or `## Features` contains only architecture headlines with no sub-feature detail |
+| 1 | Feature Enumeration | (a) Every feature from the ideation index's Must Have list appears in at least one shard. (b) Every feature has a clear scope boundary (what's in, what's out). (c) Every shard's `## Features` section contains Level-1 sub-features from the ideation domain tree (folder index + feature files) — not architecture headlines — and every sub-feature is represented in at least one section body (User Interactions, Data Model, Access Control, or Edge Cases). | Some features vague, scope unclear, or sub-features listed in `## Features` but not represented in any section body | Major Must Have features missing, or `## Features` contains only architecture headlines with no sub-feature detail |
 | 2 | Access Model | Every role has: a named role + an exhaustive list of what it CAN do + an exhaustive list of what it CANNOT do + escalation path. No role uses "standard access" without defining it. | Some roles defined but missing permission or restriction lists | No access model |
 | 3 | Data Model | Every entity has: named fields + field types + constraints + relationships with cardinality. No field uses "standard" or "typical" without defining it. | Structure present but field types or constraints missing | Absent |
 | 4 | User Flows | Every user flow has: trigger + step-by-step actions + system responses + error paths. No flow ends at "success" without defining what success looks like. | Happy path only, or flows missing error paths | None |
@@ -14,6 +14,6 @@
 > **Deep Dive audit note**: When auditing dimension 7, read each deep dive file directly — do not infer its completeness from the parent shard's reference to it. A parent shard that links to a deep dive scores ⚠️ (not ✅) if the deep dive file itself is still a skeleton. Score ✅ only when the deep dive file contains exhaustive subsystem detail that an implementer could work from without asking questions.
 
 > **Dimension 1 audit procedure**:
-> 1. Read `docs/plans/ideation/ideation-index.md` and the relevant ideation domain files (use Domain Documents table for correct paths — files may be in `domains/` or `surfaces/{name}/`) to extract the authoritative list of Level-1 sub-features per domain.
+> 1. Read `docs/plans/ideation/ideation-index.md` and the relevant ideation domain folders (use Structure Map for correct paths — folders are under `domains/` or `surfaces/{name}/`). For each domain, read the folder's `*-index.md` for the children table, then each child feature file to extract the authoritative list of Level-1 sub-features per domain.
 > 2. For each shard, open `docs/plans/ia/[NN-domain-name].md` and confirm every sub-feature from step 1 appears in the `## Features` section. Score ❌ if Must Have sub-features are missing entirely.
 > 3. For each sub-feature listed in `## Features`, verify it is represented in at least one section body (User Interactions, Data Model, Access Control, or Edge Cases). A sub-feature that appears only as a headline in `## Features` but has no corresponding detail in any section body scores ⚠️ — headline only = warning, not pass.

package/template/.agent/skills/pipeline-rubrics/references/scoring.md

@@ -21,7 +21,7 @@ Write all cross-layer findings to a `## Cross-Layer Consistency` section in the
 
 | Layer | Documents to load |
 |-------|-------------------|
-| Ideation | `docs/plans/ideation/ideation-index.md` + domain files |
+| Ideation | `docs/plans/ideation/ideation-index.md` + `ideation-cx.md` + all `*-index.md`, `*-cx.md`, and feature `.md` files recursively under `domains/` (and `surfaces/` for multi-product projects) |
 | Architecture | `docs/plans/*-architecture-design.md`, `docs/plans/ENGINEERING-STANDARDS.md` |
 | IA | `docs/plans/ia/index.md` + each shard listed + `docs/plans/ia/deep-dives/*.md` (list directory; include all files present) |
 | BE | `docs/plans/be/index.md` + each spec listed |

package/template/.agent/skills/pipeline-rubrics/references/vision-rubric.md

@@ -1,4 +1,4 @@
-# Vision Rubric (7 dimensions)
+# Vision Rubric (8 dimensions)
 
 | # | Dimension | ✅ (must meet ALL criteria) | ⚠️ | ❌ |
 |---|---|---|---|---|
@@ -9,3 +9,4 @@
 | 5 | Success Measurability | Every metric is a number with a unit and a timeframe (e.g., "p95 < 500ms at launch"). No metric uses "fast", "good", or "acceptable". | Directional only | Missing |
 | 6 | Competitive Positioning | ≥3 named competitors. Differentiation is a specific capability gap. Moat is a defensible mechanism. | Vague positioning or <3 competitors | Not addressed |
 | 7 | Open Question Resolution | Every open question has: owner + deadline + what decision it blocks. No question is listed without an owner. | Questions listed, no owners or deadlines | No questions section |
+| 8 | Structural Compliance | Every domain folder has `*-index.md` + `*-cx.md`. Role Matrix populated in every domain index. Feature files have Role Lens. Structure Map in `ideation-index.md` matches actual folder tree. No Classification Gate violations (no folders with 1 child, no flat features with ≥3 sub-features). | Structure exists but some folders missing CX or Role Matrix is partially empty | No fractal structure, or flat files used instead of folders |

package/template/.agent/skills/prd-templates/SKILL.md

@@ -52,12 +52,12 @@ Run this procedure when filling the `## Features` section of each shard skeleton
 
 ### Source
 
-Read `docs/plans/ideation/ideation-index.md` — specifically the `## Structural Classification` and `## Domain Documents` sections.
+Read `docs/plans/ideation/ideation-index.md` — specifically the `## Structural Classification` and `## Structure Map` sections.
 
-- **Single-surface projects**: Locate the relevant domain file in `docs/plans/ideation/domains/` for each shard's domain.
-- **Multi-product projects**: Use the path from the Domain Documents table in `ideation-index.md`. Domain files may be in `docs/plans/ideation/surfaces/{surface-name}/` (surface-exclusive) or `docs/plans/ideation/domains/` (shared).
+- **All project shapes**: Use the Structure Map to find the correct domain **folder** path. Each domain is a folder containing `*-index.md` (children table + Role Matrix), `*-cx.md` (cross-cuts), and child feature `.md` files.
+- **Multi-product projects**: Domain folders may be under `docs/plans/ideation/surfaces/{surface-name}/` (surface-exclusive) or `docs/plans/ideation/domains/` (shared).
 
-Match each shard to its ideation domain by name. If the ideation structure is `surfaces/`, the shard's decomposition surface (from `decompose-architecture`) tells you which surface subfolder to look in.
+Match each shard to its ideation domain by name. Walk the domain's fractal tree: read the domain index for the children list, then read each child feature file to extract sub-features. If the domain has sub-domain folders, recurse into them.
 
 ### Actor + Goal Format Rule
 
@@ -73,12 +73,12 @@ List sub-features as bullet points in the `## Features` section. Group by functi
 
 ### `[THIN — review with user]` Fallback Rule
 
-If a shard's domain has no corresponding ideation domain file (the domain was introduced during architecture design, not ideation — check the `ideation-index.md` Domain Documents table for both `domains/` and `surfaces/` paths), mark the skeleton with `[THIN — review with user]` at the top of `## Features` and seed from the architecture design description instead.
+If a shard's domain has no corresponding ideation domain folder (the domain was introduced during architecture design, not ideation — check the `ideation-index.md` Structure Map for paths under `domains/` and `surfaces/`), mark the skeleton with `[THIN — review with user]` at the top of `## Features` and seed from the architecture design description instead.
 
 At the validation step, the user must confirm whether to:
 - Keep the shard separate
 - Merge it into an adjacent shard
-- Add missing sub-features from ideation
+- Add missing sub-features from ideation (create a domain folder if needed)
 
 ### Directory Example
 
@@ -88,8 +88,8 @@ Seeded skeletons live in the `docs/plans/ia/` directory (or per-surface director
 ```
 docs/plans/ia/
 ├── 00-infrastructure.md
-├── 01-user-accounts.md      ← ## Features seeded from ideation/domains/user-accounts.md
-├── 02-content-library.md    ← ## Features seeded from ideation/domains/content-library.md
+├── 01-user-accounts.md      ← ## Features seeded from ideation/domains/01-user-accounts/ (index + feature files)
+├── 02-content-library.md    ← ## Features seeded from ideation/domains/02-content-library/ (index + feature files)
 ├── ...
 ```
 
@@ -97,9 +97,9 @@ docs/plans/ia/
 ```
 docs/plans/desktop/ia/
 ├── 00-infrastructure.md
-├── 01-operations.md         ← ## Features seeded from ideation/surfaces/desktop/operations.md
-├── 02-inventory.md          ← ## Features seeded from ideation/surfaces/desktop/inventory.md
+├── 01-operations.md         ← ## Features seeded from ideation/surfaces/desktop/01-operations/ (index + feature files)
+├── 02-inventory.md          ← ## Features seeded from ideation/surfaces/desktop/02-inventory/ (index + feature files)
 
 docs/plans/shared/ia/
-├── 01-device-history.md     ← ## Features seeded from ideation/domains/device-history.md
+├── 01-device-history.md     ← ## Features seeded from ideation/domains/01-device-history/ (index + feature files)
 ```

package/template/.agent/skills/prd-templates/references/decomposition-templates.md

@@ -18,7 +18,7 @@ For each shard, create at `docs/plans/ia/[NN-domain-name].md`:
 [1-2 sentence description of this domain's scope]
 
 ## Features
-[Level-1 sub-features from the relevant ideation domain file for this domain. Check `ideation-index.md` Domain Documents table for the correct path — files may be in `domains/` or `surfaces/{name}/` depending on structural classification. NOT architecture-level headlines. See /decompose-architecture-structure Step 5 for seeding instructions.]
+[Level-1 sub-features from the relevant ideation domain folder for this domain. Check `ideation-index.md` Structure Map for the correct folder path — folders are under `domains/` or `surfaces/{name}/`. Read the folder's `*-index.md` for the children table, then each child feature file. NOT architecture-level headlines. See /decompose-architecture-structure Step 5 for seeding instructions.]
 
 ## User Interactions
 [To be filled during /write-architecture-spec]

package/template/.agent/skills/prd-templates/references/engineering-standards-template.md

@@ -102,9 +102,11 @@ Use this template when creating `docs/plans/ENGINEERING-STANDARDS.md`. Fill in c
 
 ## Security
 - Dependency audit: [e.g., npm audit on every CI run]
+- Dependency audit enforcement: [e.g., Fail on HIGH/CRITICAL, Warn on MODERATE]
 - Secret scanning: [tool/approach]
 - CSP policy: [strict/relaxed + details] (web surfaces)
 - Code signing: [signing certificate strategy] (desktop/mobile surfaces)
+- Security testing tool: [e.g., OWASP ZAP for web, MobSF for mobile, or none] (surface-specific dynamic security scan)
 
 ## Code Quality
 - Max file length: [e.g., 300 lines]

package/template/.agent/skills/prd-templates/references/fractal-cx-template.md

@@ -0,0 +1,58 @@
+# {Node Name} — Cross-Cuts
+
+> **Level**: {surface | domain | sub-domain}
+> **Scope**: Connections between children of [{parent}](../{parent}-index.md)
+
+## Cross-Cut Map
+
+| # | Source | Target | Relationship | Roles Affected | Confidence | Evidence |
+|---|--------|--------|--------------|----------------|------------|----------|
+| CX-01 | [child-A](./path) | [child-B](./path) | _what the interaction is_ | Tech, Owner | High | _specific evidence from exploration_ |
+| CX-02 | [child-C](./path) | [{external-node}](../../path) | _cross-level interaction_ | Tech | Medium | _evidence_ |
+
+> **Confidence levels:** High (confirmed with evidence), Medium (strong signal, needs validation), Low (hypothesis)
+>
+> **Cross-level references:** When a cross-cut spans levels (e.g., a feature in one surface touches a domain in another), record it here at the HIGHER level with a link path to the specific lower-level item. The detail of HOW they interact lives in the LOWER-level CX file.
+>
+> **Cross-references:** When referencing a CX entry from another file, use format `{filename}#CX-NN` (e.g., `ai-assistant-cx.md#CX-03`)
+
+---
+
+## Cross-Cut Details
+
+### CX-01: {Source} ↔ {Target}
+
+**Relationship**: _Detailed description of how these two children interact. What data flows between them? What triggers what?_
+
+**Role scoping**:
+- **{Role 1}**: _what this role experiences at this intersection_
+- **{Role 2}**: _what this role experiences_
+- **{Role 3}**: _not affected / no visibility_
+
+**Synthesis questions answered**:
+1. **Shared state conflict**: _Who owns the entity? What's the merge strategy if both sides modify it?_
+2. **Trigger chain**: _Does A trigger B? What happens if B fails — rollback? Compensating action? Is it sync or async?_
+3. **Permission intersection**: _Does a permission in A affect what you can do in B?_
+4. **Notification fan-out**: _Does an event in A notify actors in B?_
+5. **State transition conflict**: _Can A and B race? What's the consistency impact?_
+
+---
+
+_Repeat the Cross-Cut Details section for each CX entry in the map._
+
+---
+
+## Rejected Pairs
+
+| # | Source | Target | Reason for Rejection |
+|---|--------|--------|---------------------|
+| R-01 | _{child-A}_ | _{child-B}_ | _No shared state, no trigger dependency, independent lifecycles_ |
+
+> **Notes for agents:**
+> - This template is used at EVERY folder level in the fractal structure
+> - CX files ONLY connect children at their own level — a surface CX connects domains, a domain CX connects sub-domains, a sub-domain CX connects features
+> - CX entries use sequential `CX-NN` numbering within each file, starting at CX-01
+> - Always include role scoping — every cross-cut affects specific roles, not all roles equally
+> - Rejected pairs are valuable — they show the agent considered the interaction and dismissed it with reasoning
+> - The 5 synthesis questions should be answered for EVERY confirmed cross-cut (CX entries with High confidence)
+> - For Medium/Low confidence entries, the synthesis questions can be deferred to later drilling passes

package/template/.agent/skills/prd-templates/references/fractal-feature-template.md

@@ -0,0 +1,93 @@
+# Feature: {Feature Name}
+
+> **Number**: {NN.NN.NN}
+> **Parent**: [{sub-domain-name}](./{sub-domain}-index.md)
+> **Status**: [SURFACE] / [PARTIAL] / [DEEP] / [EXHAUSTED]
+> **Last updated**: {timestamp}
+
+## Overview
+
+_What this feature is, why it exists, what user problem it solves. 2-3 sentences._
+
+## Role Lens
+
+| Role | Access | What They See/Do |
+|------|--------|-------------------|
+| {Persona 1} | Full | _specific behavior for this role — actions, views, capabilities_ |
+| {Persona 2} | Config | _specific behavior — what they configure, what they see_ |
+| {Persona 3} | Read-only | _specific behavior — what they can view, what's hidden_ |
+| {Persona 4} | None | _not visible — brief note on why or what they see instead_ |
+
+> **Access levels**: Full · Config · Read-only · Reports · None
+>
+> **Rules:**
+> - Every feature file MUST have a Role Lens table — no exceptions
+> - Use persona names from `meta/personas.md`
+> - "What They See/Do" must be SPECIFIC to this feature, not generic role descriptions
+> - If a persona has "None" access, still list them — the explicit absence is valuable for downstream spec writers
+> - This is the implementation-ready detail that IA/BE/FE spec writers consume directly
+
+## Behavior
+
+_Detailed description of the feature's behavior._
+
+### Happy Path
+
+_Step-by-step user interaction for the normal/expected case. Number each step._
+
+1. _User does X_
+2. _System responds with Y_
+3. _User confirms Z_
+4. _System completes action, shows confirmation_
+
+### Edge Cases / Failure Modes
+
+| Scenario | What Happens | User Sees |
+|----------|-------------|-----------|
+| _edge case 1_ | _system behavior_ | _error message or fallback UI_ |
+| _edge case 2_ | _system behavior_ | _error message or fallback UI_ |
+
+### States
+
+| State | Trigger | What User Sees |
+|-------|---------|---------------|
+| Loading | _action initiated_ | _spinner, skeleton, progress bar_ |
+| Empty | _no data exists yet_ | _empty state with CTA_ |
+| Populated | _data loaded_ | _populated view_ |
+| Error | _request failed_ | _error message with retry option_ |
+| Partial | _incomplete data_ | _partial view with missing-data indicator_ |
+
+## Deep Think Annotations
+
+| # | Hypothesis | Source | Outcome |
+|---|-----------|--------|---------|
+| DT-01 | _hypothesis about what this feature needs_ | _reasoning or industry precedent_ | ✅ CONFIRMED / ❌ REJECTED: _reason_ |
+
+> Log every Deep Think hypothesis — both confirmed and rejected. This is the audit trail showing the agent explored beyond the obvious.
+
+## Cross-Cut Notes
+
+_Quick references to how this feature interacts with features in other domains/sub-domains. These are pointers — detailed cross-cut analysis lives in the parent's CX file._
+
+- Touches **{Domain/Sub-domain/Feature}** ([path](../../../path)) — _why: shared entity, trigger dependency, permission, etc._
+- Consumed by **{Surface/Domain}** via API — _why: spoke surface reads this data through platform API_
+
+> For detailed cross-cut analysis (synthesis questions, role scoping), see the CX file at the appropriate level.
+
+## Decisions
+
+| # | Decision | Context |
+|---|----------|---------|
+| D-01 | _what was decided_ | _why this was the right call_ |
+
+## Open Questions
+
+| # | Question | Owner | Deferred To |
+|---|----------|-------|-------------|
+| Q-01 | _question_ | User / Agent / /create-prd | _pipeline stage_ |
+
+> **Notes for agents:**
+> - Feature files are LEAF NODES — they are `.md` files, never folders
+> - If a feature reveals 2+ interacting capabilities during drilling, it should be PROMOTED to a sub-domain (see Reactive Depth Protocol in `idea-extraction/SKILL.md`)
+> - Status markers: `[SURFACE]` = identified only, `[PARTIAL]` = some depth, `[DEEP]` = all sections filled with edge cases, `[EXHAUSTED]` = Deep Think yields zero hypotheses + user confirms nothing missing
+> - The Role Lens is the PRIMARY output consumed by `/write-fe-spec` and `/write-be-spec` — make it thorough

package/template/.agent/skills/prd-templates/references/fractal-node-index-template.md

@@ -0,0 +1,55 @@
+# {Node Name} — Index
+
+> **Level**: {surface | domain | sub-domain}
+> **Parent**: [{parent-name}](../{parent}-index.md)
+> **Status**: [SURFACE] / [BREADTH] / [DEEP] / [EXHAUSTED]
+> **Last updated**: {timestamp}
+
+## Overview
+
+_What this node contains and why it exists. 2-3 sentences describing the domain or sub-domain's purpose and scope._
+
+## Children
+
+| # | Name | Type | Path | Status | Deep Think |
+|---|------|------|------|--------|------------|
+| 01 | _{child-name}_ | domain / sub-domain / feature | [01-slug](./01-slug/) or [01.01-slug.md](./01.01-slug.md) | [SURFACE] | _N hypotheses_ |
+| 02 | ... | ... | ... | ... | ... |
+
+> **Type column values:**
+> - `domain` — a top-level grouping within a surface (folder with index + CX)
+> - `sub-domain` — a grouping within a domain that has 2+ interacting capabilities (folder with index + CX)
+> - `feature` — a leaf node describing a single capability (.md file)
+
+## Role Matrix
+
+| Child | {Persona 1} | {Persona 2} | {Persona 3} | {Persona 4} |
+|-------|-------------|-------------|-------------|-------------|
+| 01-child | ✅ Full | ⚙️ Config | 👁️ View | ❌ None |
+| 02-child | ✅ Full | ✅ Full | ❌ None | ❌ None |
+
+> **Legend**: ✅ Full access · ⚙️ Configuration only · 👁️ Read-only · 📊 Reports only · ❌ No access
+>
+> **Rules:**
+> - Persona names come from `meta/personas.md` — use short names (e.g., "Tech", "Owner", "CSR", "Consumer")
+> - NEVER redefine a persona here — reference only
+> - Only list children that exist — the matrix grows as children are added
+> - Access icons are shorthand; detailed per-role behavior lives in each feature file's **Role Lens**
+
+## Decision Log
+
+| # | Decision | Context | Source |
+|---|----------|---------|--------|
+| D-01 | _what was decided_ | _why this was the right call_ | _conversation / document / user directive_ |
+
+## Open Questions
+
+| # | Question | Owner | Deferred To |
+|---|----------|-------|-------------|
+| Q-01 | _question_ | User / Agent / /create-prd | _pipeline stage_ |
+
+> **Notes for agents:**
+> - This template is used at EVERY folder level in the fractal structure (surface, domain, sub-domain)
+> - The content differs by level — a surface index lists domains, a domain index lists sub-domains/features
+> - Status propagates upward: all children `[EXHAUSTED]` → node is `[EXHAUSTED]`; all `[DEEP]`+ → node is `[DEEP]`
+> - When adding a new child, update BOTH the Children table AND the Role Matrix

package/template/.agent/skills/prd-templates/references/ideation-crosscut-template.md

@@ -1,57 +1,36 @@
-# Cross-Cut Ledger
+# Global Cross-Cuts — {{PROJECT_NAME}}
 
-> This ledger is accumulated incrementally at every level of ideation.
-> It is NOT built in a single pass. Each level adds resolution.
-> Never clear entries — this is the audit trail.
+> **Scope**: Cross-surface interactions for multi-product projects, or cross-domain interactions for single-surface projects.
+> **Format**: Index + one-line summary. Detailed synthesis lives in lower-level CX files.
 
-## Ledger
+## Cross-Surface Interaction Map
 
-### Level 0 — Surface Guesses (from domain map)
+> Each row records that an interaction EXISTS between two surfaces or top-level domains. The Detail column links to the lower-level CX file where the full synthesis questions are answered.
 
-_Noted during global domain mapping. Low confidence, not yet validated._
+| # | Source Surface/Domain | Target Surface/Domain | Summary | Roles | Detail |
+|---|----------------------|----------------------|---------|-------|--------|
+| CX-01 | _Web / Consumer Platform_ | _Desktop / Shop Ops_ | _Desktop diagnostic workflow consumes web supplier data via API_ | Tech, Owner | [detail](surfaces/desktop/desktop-cx.md#CX-03) |
+| CX-02 | _Web / Device History_ | _Mobile / Device Guardian_ | _Mobile app syncs with web device history for owner verification_ | Consumer | [detail](surfaces/mobile/mobile-cx.md#CX-01) |
 
-| Domain A | Domain B | Suspected Connection | Status |
-|----------|----------|---------------------|--------|
-| _Domain 01_ | _Domain 05_ | _Likely share customer entity_ | `pending` |
+> **Rules:**
+> - This file is an INDEX with one-line summaries — not the source of truth for cross-cut details
+> - Detailed synthesis (5 questions, role scoping) lives in the lower-level CX file linked in the Detail column
+> - For single-surface projects, this file covers cross-DOMAIN interactions (same content as would appear in a surface-level CX)
+> - For multi-product projects, this file covers cross-SURFACE interactions
+> - Use `CX-NN` numbering. This file's entries are distinct from CX entries in lower-level files.
+> - When referencing from other files, use `ideation-cx.md#CX-NN`
 
-### Level 1 — Sub-Domain Connections (from breadth sweep)
+## Shared Domain Consumption _(multi-product only)_
 
-_Noted during domain breadth mapping. Medium confidence, connection identified at sub-area level._
+> Which shared domains are consumed by which spoke surfaces, and through what mechanism.
 
-| Domain A.Sub-Area | Domain B.Sub-Area | Connection | Status |
-|-------------------|-------------------|------------|--------|
-| _01.Inventory_ | _05.Supplier Catalog_ | _Parts lookup cross-references supplier data_ | `pending` |
+| Shared Domain | Owner | Consumed By | Mechanism | Detail |
+|--------------|-------|-------------|-----------|--------|
+| _Device History_ | Web (hub) | Desktop, Mobile | REST API | [web/02-device-history-cx.md](surfaces/web/02-device-history/device-history-cx.md) |
+| _Payments_ | Web (hub) | Desktop | REST API | [web/03-payments-cx.md](surfaces/web/03-payments/payments-cx.md) |
 
-### Level 2+ — Evidence-Backed (from vertical drilling)
+## Rejected Cross-Surface Pairs
 
-_Confirmed during vertical drilling with specific evidence. High confidence._
-
-| Domain A.Sub-Area.Feature | Domain B.Sub-Area.Feature | Evidence | Status |
-|--------------------------|--------------------------|----------|--------|
-| _02.Inventory.Purgatory_ | _01.Payments.PreAuth_ | _Pre-auth clears purgatory on completion_ | `✅ confirmed` |
-
-## Synthesis Outcomes
-
-For each confirmed pair, the five synthesis questions have been asked and answered.
-
-### [Interaction Name]: Domain A × Domain B
-
-**Connection**: _One-sentence description of the interaction._
-
-1. **Shared state conflict**: _Who owns the entity? What's the merge strategy?_
-2. **Trigger chain**: _Does A trigger B? Rollback if B fails? Sync or async?_
-3. **Permission intersection**: _Does permission in A affect B?_
-4. **Notification fan-out**: _Does event in A notify actors in B?_
-5. **State transition conflict**: _Can A and B race? Data consistency impact?_
-
-**Outcome**: `✅ confirmed → [Interaction Name]` | `❌ rejected: [reason]`
-
----
-
-_Repeat Synthesis Outcomes for each confirmed cross-cut pair._
-
-## Rejected Pairs
-
-| Domain A | Domain B | Reason for Rejection |
-|----------|----------|---------------------|
-| _Domain 03_ | _Domain 07_ | _No shared state, no trigger dependency, independent lifecycles_ |
+| # | Surface A | Surface B | Reason for Rejection |
+|---|-----------|-----------|---------------------|
+| R-01 | _Desktop_ | _Mobile_ | _No direct interaction — both consume web API independently_ |

package/template/.agent/skills/prd-templates/references/ideation-index-template.md

@@ -18,20 +18,29 @@
 
 ## Structural Classification
 
-- **Project Shape**: [single-surface | multi-surface-shared | multi-product]
+- **Project Shape**: [single-surface | multi-surface-shared | multi-product-hub | multi-product-peer]
+- **Hub Surface** _(hub-and-spoke only)_: [surface name that owns shared domains]
 - **Surfaces**: [list of identified surfaces, e.g., "Web (Astro/React), Desktop (Rust/Tauri), Mobile (React Native)" — or "N/A" for single-surface]
 - **Classification Basis**: [how this was determined — "detected from document", "user interview", "inferred from one-liner"]
 
+> **Project Shapes:**
+> - `single-surface` — One platform. Domains are top-level children of `ideation/`.
+> - `multi-surface-shared` — 2+ platforms, same stack, >80% shared logic. Domains at top level with surface annotations.
+> - `multi-product-hub` — 2+ platforms, one is the central platform/API. Hub owns shared domains. Spokes reference via CX.
+> - `multi-product-peer` — 2+ platforms, no primary. `shared/` folder as a peer for cross-surface domains.
+
 ## Progress Summary
 
 | Metric | Value |
 |--------|-------|
+| Total surfaces | _N_ |
 | Total domains | _N_ |
-| SURFACE | _N_ |
-| BREADTH | _N_ |
-| DEEP | _N_ |
-| EXHAUSTED | _N_ |
-| Cross-cut pairs confirmed | _N_ |
+| Total leaf features | _N_ |
+| Max depth reached | _N_ |
+| Leaf nodes at [SURFACE] | _N_ |
+| Leaf nodes at [DEEP] | _N_ |
+| Leaf nodes at [EXHAUSTED] | _N_ |
+| CX entries confirmed | _N_ |
 | Deep Think hypotheses confirmed | _N_ |
 | Deep Think hypotheses rejected | _N_ |
 
@@ -48,72 +57,55 @@
 | Competitive Landscape | [competitive-landscape.md](meta/competitive-landscape.md) | _status_ |
 | Constraints | [constraints.md](meta/constraints.md) | _status_ |
 
-### Domain Documents
-
-> **Path convention:** For single-surface projects, domains live in `domains/NN-slug.md`.
-> For multi-product projects, surface-exclusive domains live in `surfaces/{surface}/NN-slug.md`
-> and shared domains live in `domains/NN-slug.md`.
-
-| # | Domain | Surface | Path | Status | Sub-areas | Deep Think |
-|---|--------|---------|------|--------|-----------|------------|
-| 01 | _Domain Name_ | _surface or shared_ | [01-domain-slug.md](domains/01-domain-slug.md) | `[SURFACE]` | _N_ sub-areas | _N_ hypotheses |
-
-_For multi-product projects, group domains by surface:_
-
-#### Surface: _Surface Name_
-
-| # | Domain | Path | Status | Sub-areas | Deep Think |
-|---|--------|------|--------|-----------|------------|
-| 01 | _Domain Name_ | [01-slug.md](surfaces/{surface}/01-slug.md) | `[SURFACE]` | _N_ | _N_ |
+### Global Cross-Cuts
 
-#### Shared Domains
+| Document | Path |
+|----------|------|
+| Global Cross-Cuts | [ideation-cx.md](ideation-cx.md) |
 
-| # | Domain | Consumed By | Path | Status | Sub-areas | Deep Think |
-|---|--------|-------------|------|--------|-----------|------------|
-| 01 | _Domain Name_ | _surface list_ | [01-slug.md](domains/01-slug.md) | `[SURFACE]` | _N_ | _N_ |
+### Structure Map
 
-### Cross-Cut Ledger
+> **For single-surface projects**, domains are listed directly below.
+> **For multi-product projects**, expand each surface section.
+> Every domain below is a FOLDER containing: `{domain}-index.md`, `{domain}-cx.md`, and child features/sub-domains.
 
-| Document | Path |
-|----------|------|
-| Cross-Cut Ledger | [cross-cut-ledger.md](cross-cuts/cross-cut-ledger.md) |
+#### _{Surface Name or "Top-Level Domains" for single-surface}_
 
-## Domain Map
+| # | Domain | Path | Status | Children | Depth | Deep Think |
+|---|--------|------|--------|----------|-------|------------|
+| 01 | _Domain Name_ | [01-slug/](./01-slug/) | `[SURFACE]` | _N children_ | _N levels_ | _N hypotheses_ |
 
-Visual status of all domains with sub-area breakdowns:
+_Repeat surface sections for multi-product projects._
 
-```
-Domain 01: [Domain Name] [STATUS]
-  ├── Sub-area A [STATUS] — N sub-topics
-  ├── Sub-area B [STATUS] — N sub-topics
-  └── Sub-area C [STATUS] — N sub-topics
+#### Hub-Owned Shared Domains _(hub-and-spoke only)_
 
-Domain 02: [Domain Name] [STATUS]
-  ├── ...
-  └── ...
-```
+_Shared domains live inside the hub surface's domain tree. Listed here for visibility._
 
-Status markers: `[SURFACE]` → `[BREADTH]` → `[DEEP]` → `[EXHAUSTED]`
+| # | Domain | Hub Path | Consumed By | Status |
+|---|--------|----------|-------------|--------|
+| NN | _Domain Name_ | [web/NN-slug/](surfaces/web/NN-slug/) | Desktop, Mobile | `[SURFACE]` |
 
 ## Decision Log
 
-Numbered decisions with source references. Each decision links to the domain file where it was made.
+Numbered decisions with source references.
 
 | # | Decision | Source | Domain |
 |---|----------|--------|--------|
-| 1 | _Decision description_ | _Discussion context_ | [domain-file.md](domains/NN-domain.md) |
+| D-01 | _Decision description_ | _Discussion context_ | [domain-index.md](./path) |
 
 ## MoSCoW Summary
 
+> Features reference their fractal path. Path format: `{surface}/{domain}.{sub-domain}.{feature}`
+
 ### Must Have
-- _Feature 1_ → Domain NN
-- _Feature 2_ → Domain NN
+- _Feature 1_ → `web/01.02.01` ([link](./path/01.02.01-feature.md))
+- _Feature 2_ → `desktop/01.01.03` ([link](./path/01.01.03-feature.md))
 
 ### Should Have
-- _Feature 3_ → Domain NN
+- _Feature 3_ → `web/02.01` ([link](./path))
 
 ### Could Have
-- _Feature 4_ → Domain NN
+- _Feature 4_ → `desktop/01.03.02.04` ([link](./path))
 
 ### Won't Have (Now)
 - _Feature 5_ — Reason for exclusion

package/template/.agent/skills/prd-templates/references/slice-completion-gates.md

@@ -18,4 +18,12 @@ Non-FE slices skip this block.
 - [ ] No `// DECISION:` annotations exist for behaviors that are actually specified in the BE spec or IA shard (i.e., no spec-defined behavior was treated as an undocumented implementation decision)
 - [ ] The {{CONTRACT_LIBRARY}} contract written in Step 2 matches the delivered implementation field-for-field — no fields added, removed, or renamed during implementation without a corresponding contract update
 
+## Resource Cleanup Gate (all slices)
+
+- [ ] Every database client or connection created in this slice has a corresponding cleanup call (`disconnect`, `close`, `end`, `dispose`) in a `finally` block or lifecycle hook
+- [ ] Every event listener or subscription registered in UI components has a corresponding cleanup in the component's unmount/destroy lifecycle
+- [ ] Every `setInterval` or `setTimeout` with a stored reference has a corresponding `clearInterval`/`clearTimeout` on cleanup
+- [ ] No file handles or streams are opened without corresponding `close`/`destroy` calls
+- [ ] If using connection pools — pool size is configured (not left at framework default) and documented via code comment: `// POOL: max=N, reason=...`
+
 > ❌ STOP — Do not call `notify_user` if any of the above are unchecked. Fix the gap and re-run the Test Cmd from the surface stack map.

package/template/.agent/skills/prd-templates/references/vision-template.md

@@ -4,7 +4,7 @@ Use this template when compiling `docs/plans/vision.md` as the human-readable ex
 
 > **Important**: `vision.md` is a summary document for human consumption. The pipeline reads
 > `docs/plans/ideation/ideation-index.md` directly — not this file. All the depth, domain
-> files, cross-cut ledger, and structured data live in the `ideation/` folder.
+> files, CX files, and structured data live in the `ideation/` folder's fractal tree.
 
 ```markdown
 # [Project Name] — Vision
@@ -12,7 +12,7 @@ Use this template when compiling `docs/plans/vision.md` as the human-readable ex
 > One-sentence pitch: [from Step 4]
 
 > **This is a human-readable project summary.** For pipeline-grade detail, see
-> [ideation-index.md](ideation/ideation-index.md) and the domain files it references.
+> [ideation-index.md](ideation/ideation-index.md) and the fractal domain tree it references.
 
 ## Problem Statement
 [Condensed from `meta/problem-statement.md`]
@@ -25,26 +25,26 @@ Not the full 6-field exploration — that detail stays in the personas file.]
 [2-3 paragraphs describing what the product does and why it matters.]
 
 ## Domain Map
-[One paragraph per domain, condensed from the ideation domain files (paths in `ideation-index.md` Domain Documents table).
-Each domain links to its full file.]
+[One paragraph per domain, condensed from the ideation domain folders (paths in `ideation-index.md` Structure Map).
+Each domain links to its folder's index file.]
 
 ## Feature Inventory (MoSCoW)
 ### Must Have (Phase 1)
-[Feature names + one-line description. Links to domain files for drill-down detail.]
+[Feature names + one-line description. Links to domain folder index files for drill-down detail.]
 ### Should Have (Phase 2)
 [Feature names + one-line description.]
 ### Could Have (Phase 3+)
 ### Won't Have (explicitly excluded)
 
 ## Key Cross-Cutting Interactions
-[Top confirmed interactions from `cross-cuts/cross-cut-ledger.md`.
-Full synthesis detail stays in the ledger.]
+[Top confirmed interactions from `ideation-cx.md` (global) and domain-level `*-cx.md` files.
+Full synthesis detail stays in the CX files.]
 
 ## Constraints Summary
 [Condensed from `meta/constraints.md` — budget, timeline, team, compliance, performance, surfaces.]
 
 ## Success Metrics
-[Key metrics with concrete targets. Full details in relevant domain files.]
+[Key metrics with concrete targets. Full details in relevant domain folder feature files.]
 
 ## Competitive Landscape
 [Condensed from `meta/competitive-landscape.md` — competitors, differentiation, moat.]

package/template/.agent/skills/resolve-ambiguity/SKILL.md

@@ -50,7 +50,7 @@ If these files contain `{{PLACEHOLDER}}` values, the information hasn't been dec
 **Check second — the pipeline's own output**
 
 The answer may already exist in a document written by an earlier pipeline stage:
-- `docs/plans/ideation/ideation-index.md` + domain files — Problem, personas, features, constraints, domain map
+- `docs/plans/ideation/ideation-index.md` + fractal domain tree (folder `*-index.md`, `*-cx.md`, and feature files) — Problem, personas, features, constraints, domain map
 - `docs/plans/*-architecture-design.md` — Tech stack, system design, security model
 - `docs/plans/ENGINEERING-STANDARDS.md` — Quality thresholds, performance budgets
 - `docs/plans/ia/*.md` — IA shards (features, data models, access control, edge cases)