cfsa-antigravity 2.14.0 → 2.15.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cfsa-antigravity",
-  "version": "2.14.0",
+  "version": "2.15.0",
   "description": "CFSA Pipeline — Constraint-First Specification Architecture for AI agents. Production-grade from line one.",
   "scripts": {
     "changeset": "changeset",

package/template/.agent/kit-sync.md

@@ -1,6 +1,6 @@
 # Kit Sync State
 
 upstream: https://github.com/RepairYourTech/cfsa-antigravity
-last_synced_commit: 89e129286cdbd5e33d6617d81cde4450f2dac77e
-last_synced_at: 2026-03-20T17:29:41Z
-kit_version: 2.14.0
+last_synced_commit: 7c5b0504d422958d0c36cf83768a7b12d3a6ab2a
+last_synced_at: 2026-03-20T18:30:16Z
+kit_version: 2.15.0

package/template/.agent/workflows/create-prd-architecture.md

@@ -38,6 +38,25 @@ Read the engagement tier protocol (`.agent/skills/prd-templates/references/engag
 
 ---
 
+## 0.5. Ideation context reload
+
+> **This step is mandatory.** Shards run in separate conversations — ideation context from the orchestrator is lost. Reload it here.
+
+1. Read `docs/plans/ideation/ideation-index.md` — extract: Structure Map (domain list + paths), MoSCoW Summary (full feature inventory), Engagement Tier, persona list
+2. Read `docs/plans/ideation/meta/constraints.md` — extract: Project Surfaces, compliance constraints, hard/soft constraints
+3. Read `docs/plans/ideation/ideation-cx.md` (global cross-cuts) — extract: cross-domain data dependencies, trigger chains, shared entity ownership. Then read each domain-level `{domain}-cx.md` listed in the Structure Map
+4. If `## Ideation Digest` exists in `docs/plans/architecture-draft.md` → use it as the structured feature inventory. Otherwise, read domain index files (`{domain}/{domain}-index.md`) directly per the deep ideation loading protocol (`.agent/skills/prd-templates/references/deep-ideation-loading-protocol.md`)
+
+**How this context feeds downstream steps:**
+- Component diagram (4.1) ← domain boundaries from domain indexes, trigger chains from CX files
+- Data flow (4.2) ← cross-domain dependencies from CX files, persona access from role matrices
+- Data strategy (5) ← key entities from domain children tables, shared entities from CX
+- Data placement (5.1) ← surface constraints from constraints.md
+
+> ❌ Do NOT proceed to Step 4 until all ideation context is loaded. Do NOT rely solely on architecture-draft.md — it is the agent's prior output, not the user's ideation.
+
+---
+
 ## 4. System architecture
 
 Read `.agent/skills/api-design-principles/SKILL.md` for API surface design.

package/template/.agent/workflows/create-prd-compile.md

@@ -57,6 +57,16 @@ Document the agreed approach:
 
 Write the completed `## Development Methodology` section to `docs/plans/architecture-draft.md` immediately after user confirmation. Follow the write verification protocol (`.agent/skills/prd-templates/references/write-verification-protocol.md`).
 
+## 8.5. Ideation context reload for phasing
+
+> **Mandatory.** Phase complexity sizing from the digest alone loses depth information. A "12-feature domain" could be 12 flat features or 12 features with 3 levels of sub-domain nesting — very different phase capacity.
+
+1. Read `docs/plans/ideation/ideation-index.md` — extract: full MoSCoW Summary with per-domain feature counts, Structure Map with domain depths
+2. For each **Must Have domain**: read `{domain}/{domain}-index.md` — extract Children table depth, sub-domain count, and dependency markers
+3. Read CX files — extract cross-domain dependencies that constrain phase ordering (e.g., domain A must be implemented before domain B if B depends on A's data)
+
+Use this context alongside the Ideation Digest (if it exists in architecture-draft.md) when sizing phases below.
+
 ## 9. Phasing strategy
 
 Load the CI/CD skill(s) from the cross-cutting section per the skill loading protocol.

package/template/.agent/workflows/create-prd-design-system.md

@@ -40,6 +40,14 @@ Read the engagement tier protocol (`.agent/skills/prd-templates/references/engag
 5. Read `.agent/skills/prd-templates/references/design-system-decisions.md` — all decision option menus and the output template for `docs/plans/design-system.md`.
 6. Note which surfaces are in scope from `## Project Surfaces`.
 
+### Ideation workflow context
+
+> **Mandatory.** Navigation paradigms and page archetypes must be driven by actual user workflows, not abstract feature lists.
+
+7. Read the `## Structure Map` in `ideation-index.md` — identify the **3 heaviest domains** (highest feature count / deepest nesting)
+8. For each heavy domain: read `{domain}/{domain}-index.md` — extract the Children table to understand the user-facing workflows (what screens exist, what data users interact with, what actions they take)
+9. If any heavy domain has deep dives → read them for workflow complexity that affects navigation and archetype decisions
+
 ---
 
 ## 2. Decision 1 — Navigation paradigm

package/template/.agent/workflows/create-prd-security.md

@@ -39,6 +39,25 @@ Read the engagement tier protocol (`.agent/skills/prd-templates/references/engag
 
 ---
 
+## 0.5. Ideation context reload
+
+> **This step is mandatory.** Shards run in separate conversations — ideation context from the orchestrator is lost.
+
+1. Read `docs/plans/ideation/ideation-index.md` — extract: persona list (all roles), MoSCoW Summary, Engagement Tier
+2. Read `docs/plans/ideation/meta/constraints.md` — extract: compliance constraints (COPPA/PCI/HIPAA triggers), regulatory requirements, age-related constraints
+3. Read domain-level index files for **every domain that has Must Have features** — extract the **Role Matrix** from each. The role matrix shows which personas access which domain at which permission level (Full / Config / Read-only / None). This is the primary input for access control design in Step 6.
+4. Read CX files (`ideation-cx.md` + domain-level `{domain}-cx.md`) — extract trust boundaries: which domains share data across different permission levels, cross-domain escalation paths
+
+**How this context feeds downstream steps:**
+- Auth design (6.1-2) ← persona list + role matrices determine RBAC scope
+- Compliance escalation (6) ← constraints.md compliance flags trigger mandatory sections
+- Trust boundaries (6.5) ← CX cross-domain dependencies reveal attack surface
+- Integration security (7) ← ideation integration references inform threat model
+
+> ❌ Do NOT proceed to Step 6 until ideation context is loaded. "Scan the ideation output" is NOT sufficient — read the specific files listed above.
+
+---
+
 ## 6. Security model
 
 Read .agent/skills/security-scanning-security-hardening/SKILL.md and follow its defense-in-depth methodology.

package/template/.agent/workflows/create-prd-stack.md

@@ -44,6 +44,21 @@ Present the constraints map to the user before starting tech decisions *(Interac
 
 Read `.agent/skills/tech-stack-catalog/references/constraint-questions.md` for the per-axis constraint questions to ask before presenting options.
 
+## 2.7. Domain context loading for tech decisions
+
+> **This step is mandatory.** Reading `ideation-index.md` + `constraints.md` gives feature names, not feature architecture. Tech stack decisions require understanding *what the features actually do*.
+
+Before starting tech decisions, load domain context:
+
+1. Read the `## Structure Map` in `ideation-index.md` — identify all domain folders
+2. For each **Must Have domain**: read `{domain}/{domain}-index.md` to extract the Children table (sub-features, depth, complexity)
+3. For domains with **deep dives** (status `[DEEP]` or `[EXHAUSTED]`): read the deep dive files. These contain the architectural detail (multi-agent patterns, graph engines, sync protocols, embedded databases) that determines which tech stack is appropriate
+4. Read CX files (`ideation-cx.md` + domain CX files) — extract cross-domain dependencies that affect framework choices (e.g., shared AI orchestration across surfaces)
+
+**Per-axis context rule**: Before presenting tech options for any axis, identify which domain deep dives are relevant to that axis and confirm you have read them. Example: before an AI/ML framework decision, you must have read every domain file that describes AI-powered features — not just the MoSCoW bullet saying "AI diagnostics."
+
+> ❌ If a tech axis involves features with deep dives that you haven't read → **STOP** and read them before presenting options. A MoSCoW summary line is never sufficient context for a tech stack decision.
+
 ## 3. Tech stack decisions
 
 Read the **Project Surfaces** section from `docs/plans/ideation/meta/constraints.md` to determine which decision axes apply.