cfsa-antigravity 2.15.0 → 2.15.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cfsa-antigravity",
-  "version": "2.15.0",
+  "version": "2.15.1",
   "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: 7c5b0504d422958d0c36cf83768a7b12d3a6ab2a
-last_synced_at: 2026-03-20T18:30:16Z
-kit_version: 2.15.0
+last_synced_commit: b15e8bb8c155e68846530e42720e811e0585ffc6
+last_synced_at: 2026-03-20T23:23:20Z
+kit_version: 2.15.1

package/template/.agent/rules/source-before-ask.md

@@ -0,0 +1,93 @@
+---
+description: Before any question or decision, reason about what source documents are relevant, read them, then speak — never ask from summaries alone
+trigger: always_on
+---
+
+# Source Before Ask
+
+> Never present a question, decision, or recommendation to the user without first reading the source documents that inform it. Feature names are not features. Summaries are not specs.
+
+## The Rule
+
+**Before presenting ANY question, decision, option table, or recommendation to the user:**
+
+1. **Reason about relevance.** Ask yourself: "What domains, features, deep dives, CX files, or specs contain detail that affects THIS specific decision?" Think about second-order connections — a database decision doesn't just touch the "data" domain; it touches every domain that has complex query patterns, real-time sync, or graph relationships.
+
+2. **Read those documents.** Not the summary. Not the index line. The actual source files that contain the architectural detail. If a domain has deep dives (`[DEEP]` or `[EXHAUSTED]` status), read the deep dive files — they contain the information that changes the answer.
+
+3. **Cite what you found.** When presenting the question or decision, reference what you learned: "Based on the diagnostics deep dive, your multi-agent repair flow requires X, which means option A fits better than B because..."
+
+4. **Only then ask.** Now you're asking an informed question that the user can answer without doing your research for you.
+
+## The Per-Decision Research Loop
+
+This loop fires for EVERY decision point, not once per workflow:
+
+```
+For each question/decision/recommendation:
+  1. STOP — do not type anything to the user yet
+  2. THINK — what ideation/spec/CX content is relevant to THIS decision?
+     - Which domains does this decision affect?
+     - Which features have architectural constraints that change the answer?
+     - Which cross-cuts create dependencies?
+     - Which deep dives contain the detail I need?
+  3. READ — open and read those specific files now
+  4. SYNTHESIZE — what did I learn that affects this decision?
+  5. PRESENT — now ask the question, citing what you found
+```
+
+## Common Relevance Patterns
+
+| Decision Type | What to Read Before Asking |
+|--------------|---------------------------|
+| Frontend framework | Every domain with UI complexity, responsive requirements, offline-first features, real-time updates |
+| Database / persistence | Every domain with complex data relationships, sync requirements, search patterns, graph traversals |
+| AI/ML framework | Every domain that mentions AI, ML, diagnostics, recommendations, automation, agents |
+| Auth / security | Every domain's role matrix, CX files for cross-domain permission boundaries |
+| API design | Every domain's CX files for cross-domain data flow, every deep dive with integration points |
+| Deployment / hosting | Constraints file, every surface's performance requirements, offline capabilities |
+| State management | Every domain with real-time features, collaborative editing, optimistic updates |
+| Caching strategy | Every domain's query patterns, hot paths, data freshness requirements |
+
+## Why
+
+| Without this rule | With this rule |
+|---|---|
+| Agent asks "which database?" based on a MoSCoW bullet | Agent reads the graph traversal deep dive and knows you need a graph-capable store |
+| User has to say "go read the docs" 15 times per session | Agent arrives at each question already informed |
+| Decisions feel generic — could apply to any project | Decisions are grounded in YOUR project's specific architecture |
+| Context evaporates after Step 0.5's bulk loading | Context is refreshed per-decision, exactly when it matters |
+| Agent asks questions the ideation already answered | Agent knows what's been decided and asks only what's open |
+
+## Applies To
+
+**Every pipeline stage.** This is not limited to `/create-prd`:
+
+| Stage | What This Means |
+|-------|----------------|
+| `/create-prd-stack` | Before each axis question, read the domains that axis touches |
+| `/create-prd-architecture` | Before each component design, read the domains that component serves |
+| `/create-prd-security` | Before each security item, read the role matrices and CX trust boundaries |
+| `/write-architecture-spec` | Before each interaction design, read the relevant domain deep dives |
+| `/write-be-spec` | Before each endpoint design, read the IA shard interactions that endpoint serves |
+| `/write-fe-spec` | Before each component spec, read the BE endpoints and IA interactions it consumes |
+| `/implement-slice` | Before each implementation decision, read the relevant specs |
+
+## What Gets Flagged
+
+| Pattern | Verdict |
+|---------|---------|
+| "Which database do you prefer?" without reading any domain files | ❌ Rejected. Read the domains first — the answer might be obvious. |
+| Presenting 3 framework options with generic pros/cons | ❌ Rejected. Pros/cons must reference THIS project's specific needs. |
+| Asking a question the ideation deep dives already answered | ❌ Rejected. Read before asking. |
+| "Based on your diagnostics domain's multi-agent flow, you need X" | ✅ Correct. Informed by source material. |
+| Citing specific CX dependencies when recommending architecture | ✅ Correct. Research before recommendation. |
+| Re-reading a deep dive mid-workflow because THIS question needs it | ✅ Correct. Per-decision freshness. |
+
+## The Litmus Test
+
+Before sending any question to the user, ask yourself:
+
+> **"Could a user reasonably respond: 'Did you even read my ideation docs?'"**
+
+If the answer is yes — you didn't do this rule. Stop. Read. Then ask.

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

@@ -71,14 +71,15 @@ Read .agent/skills/tech-stack-catalog/SKILL.md and follow its per-axis constrain
 Score Fit from 1–5 based on how well the option matches the constraints map. If constraints eliminate all but 1-2 options, present only those with a note explaining why others were eliminated.
 
 **Per-axis flow**:
-1. Ask the constraint questions for this axis
-2. Filter options based on answers
-3. Present the filtered option table with recommendation
-4. Follow the decision confirmation protocol (`.agent/skills/prd-templates/references/decision-confirmation-protocol.md`) — tier-aware.
-5. Fire bootstrap with only that key: read `.agent/workflows/bootstrap-agents.md` and call with `PIPELINE_STAGE=create-prd` + the confirmed key. **HARD GATE**: Follow the bootstrap verification protocol (`.agent/skills/prd-templates/references/bootstrap-verification-protocol.md`). If bootstrap verification fails:
+1. **Apply rule `source-before-ask`**: Before this axis, reason about which ideation domains, deep dives, and CX files are relevant to THIS specific technology decision. Read those files now. Do NOT proceed to the constraint questions until you have read the relevant source material and can cite specific architectural details from the ideation output.
+2. Ask the constraint questions for this axis
+3. Filter options based on answers
+4. Present the filtered option table with recommendation — **citing specific ideation details** that informed your recommendation (e.g., "Based on the diagnostics deep dive's multi-agent coordination pattern, you need X")
+5. Follow the decision confirmation protocol (`.agent/skills/prd-templates/references/decision-confirmation-protocol.md`) — tier-aware.
+6. Fire bootstrap with only that key: read `.agent/workflows/bootstrap-agents.md` and call with `PIPELINE_STAGE=create-prd` + the confirmed key. **HARD GATE**: Follow the bootstrap verification protocol (`.agent/skills/prd-templates/references/bootstrap-verification-protocol.md`). If bootstrap verification fails:
    - **1st failure** → retry bootstrap once with the same key
    - **2nd failure** → **STOP**: tell the user which key failed verification and ask: "Retry, skip this skill provisioning, or abort?"
-6. Move to next axis
+7. Move to next axis
 
 > **Note on backend axis bootstrap keys**: `BACKEND_FRAMEWORK` and `API_LAYER` are distinct bootstrap keys and must each fire as a separate `/bootstrap-agents` call — do not combine them.
 > - `BACKEND_FRAMEWORK` (e.g., `Hono`, `FastAPI`, `NestJS`) → provisions the backend framework skill

package/template/AGENTS.md

@@ -148,6 +148,7 @@ Rules in `.agent/rules/` are **always active** — they apply to every task, eve
 | 🗣️ [question-vs-command](.agent/rules/question-vs-command.md) | Questions = discuss, Commands = act, Ambiguous = ask |
 | 🎯 [decision-classification](.agent/rules/decision-classification.md) | Product = user, Architecture = options, Implementation = agent |
 | ✅ [completion-checklist](.agent/rules/completion-checklist.md) | Code ≠ done. Code + tests + tracking = done |
+| 📖 [source-before-ask](.agent/rules/source-before-ask.md) | Read relevant source docs before every question — no decisions from summaries |
 
 ### Installed Skills
 

package/template/GEMINI.md

@@ -132,6 +132,7 @@ Rules in `.agent/rules/` are **always active** — they apply to every task, eve
 | 🔢 [single-question](.agent/rules/single-question.md) | One question at a time, options + pros/cons + recommendation |
 | 🐛 [debug-by-test](.agent/rules/debug-by-test.md) | Failing test before any fix — reproduce first, fix second |
 | 🔍 [skill-mcp-first](.agent/rules/skill-mcp-first.md) | Check skills and MCPs before reasoning on your own |
+| 📖 [source-before-ask](.agent/rules/source-before-ask.md) | Read relevant source docs before every question — no decisions from summaries |
 
 ### Installed Skills