cfsa-antigravity 2.19.0 → 2.19.2

package/template/.claude/skills/prd-templates/references/tdd-testing-policy.md

@@ -0,0 +1,39 @@
+# TDD Testing Policy
+
+## Assertion Depth Rule
+
+Every test must assert **at minimum**:
+- Response status code AND response body structure (not just status)
+- At least one specific field value from the response body
+- For error paths: the full error shape (code + message), not just the status code
+- Contract tests must assert both valid input accepted AND invalid input rejected with the correct error shape
+
+Tests that only assert `status == 200` without checking the response body are **insufficient** and will be flagged during QA anti-cheat audit.
+
+## Anti-Mock-Abuse Rules
+
+| Test Type | Mocking Policy |
+|-----------|---------------|
+| **Unit tests** | Mocking external dependencies allowed and expected |
+| **Integration tests** | At least one test per endpoint must hit a real test database — no mocked DB responses |
+| **E2E tests** | No mocks allowed — full stack or it doesn't count |
+
+**Banned patterns**:
+- Mocking the module under test (testing a mock of what you're building)
+- Mock chains (mocking a mock that mocks another dependency)
+- Tests where the mock returns exactly the expected value (circular, proves nothing)
+
+**Test order**: Unit → Integration → E2E (if applicable)
+
+## QA Anti-Cheat Audit
+
+Before marking tests as passing, verify:
+
+- [ ] No tests with zero assertions
+- [ ] No tautological tests (e.g., `expect(true).toBe(true)`, `expect(mock).toEqual(mock)`)
+- [ ] No `test.skip` without a `BOUNDARY:` reference and tracking issue
+- [ ] Every test that asserts a response also asserts the response body, not just the status code
+- [ ] No tests that mock the thing they're supposed to test (e.g., mocking the handler to test the handler)
+- [ ] Error path tests actually trigger the error condition — they don't just mock the error response
+
+In sequential mode, the agent self-audits against this checklist. In parallel mode, the QA-GREEN agent runs this explicitly.

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

@@ -0,0 +1,57 @@
+# Vision Document Template
+
+Use this template when compiling `docs/plans/vision.md` as the human-readable executive summary.
+
+> **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, CX files, and structured data live in the `ideation/` folder's fractal tree.
+
+```markdown
+# [Project Name] — Vision
+
+> 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 fractal domain tree it references.
+
+## Problem Statement
+[Condensed from `meta/problem-statement.md`]
+
+## Target Users
+[Condensed persona summaries from `meta/personas.md` — name + role + pain point + success criteria.
+Not the full 6-field exploration — that detail stays in the personas file.]
+
+## Solution Overview
+[2-3 paragraphs describing what the product does and why it matters.]
+
+## Domain Map
+[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 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 `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 folder feature files.]
+
+## Competitive Landscape
+[Condensed from `meta/competitive-landscape.md` — competitors, differentiation, moat.]
+
+## Key Decisions
+[Numbered list of major product decisions made during ideation.]
+
+## Open Questions
+[Anything unresolved that needs answers before architecture — with owners and target stages.]
+```

package/template/.claude/skills/prd-templates/references/workflow-checkpoint-protocol.md

@@ -0,0 +1,112 @@
+# Workflow Checkpoint Protocol
+
+> Survive context truncation. When process memory is lost, this file tells the next context exactly where you are and what to do next.
+
+## When to use
+
+Every `/create-prd` shard workflow writes and reads this checkpoint. It lives at `docs/plans/prd-working/workflow-state.md`.
+
+## Checkpoint file format
+
+The checkpoint is a markdown file with YAML-style key-value pairs. Agents must parse it on shard start and update it at every write trigger.
+
+```markdown
+# Workflow Checkpoint
+
+active_shard: .agent/workflows/create-prd-stack.md
+current_step: per-axis-flow
+current_item: Frontend Framework (STK-04)
+items_completed: [Hosting (STK-01), Database (STK-02), Auth (STK-03)]
+next_action: Read ideation files for Frontend Framework axis, write synthesis
+pending_reads:
+  - docs/plans/ideation/domains/dashboard/dashboard-deep-dive.md
+  - docs/plans/ideation/domains/diagnostics/diagnostics-deep-dive.md
+  - docs/plans/ideation/ideation-cx.md
+synthesis_written: false
+last_user_output: Confirmed Auth Provider as Supabase Auth (STK-03)
+```
+
+### Field definitions
+
+| Field | Type | Purpose |
+|-------|------|---------|
+| `active_shard` | filepath | Which workflow file to `view_file` to recover process |
+| `current_step` | string | Step identifier within the shard |
+| `current_item` | string | Axis name, decision name, or section being worked on |
+| `items_completed` | list | Already-completed items (decisions, sections, axes) |
+| `next_action` | string | Exact next thing the agent should do |
+| `pending_reads` | list | Files that MUST be read before next user-facing output |
+| `synthesis_written` | bool | Whether synthesis was written for current item |
+| `last_user_output` | string | Summary of last thing shown to the user |
+
+## Write triggers
+
+Update the checkpoint file at these moments:
+
+1. **Shard start** — initialize with shard filepath, first step, empty completed list
+2. **After reading ideation files** — update `pending_reads` to empty, note files were read
+3. **After writing synthesis** — set `synthesis_written: true`
+4. **After each item completion** — move item to `items_completed`, set next item, reset `synthesis_written: false`, populate `pending_reads` for next item from the Ideation Relevance Index
+5. **Before user-facing output** — update `last_user_output` with summary of what was presented
+6. **Shard completion** — update `current_step: complete`, `next_action: proceed to [next shard]`
+
+## Read triggers — Resumption
+
+At the start of every shard, check if `docs/plans/prd-working/workflow-state.md` exists.
+
+### If it exists and `active_shard` matches this shard:
+
+1. **Re-read the shard workflow**: `view_file` the path in `active_shard` — recover the full process
+2. **Load completed items**: Skip already-completed axes/decisions
+3. **Check `synthesis_written`**: If `false` → the agent was interrupted before writing synthesis. Read `pending_reads` files and write synthesis before doing anything else
+4. **Resume from `next_action`**: Execute exactly what the checkpoint says
+
+### If it exists and `active_shard` is a DIFFERENT shard:
+
+The previous shard finished or a different shard is running. Check `current_step`:
+- If `complete` → previous shard finished cleanly. Initialize fresh checkpoint for this shard
+- If not `complete` → previous shard was interrupted. **STOP**: "Previous shard `{active_shard}` was interrupted at `{current_item}`. Resume that shard first or confirm skip."
+
+### If it does not exist:
+
+Fresh start. Initialize the checkpoint.
+
+## Synthesis verification gate (HARD)
+
+> This gate enforces `source-before-ask`. It is not optional.
+
+**Before presenting ANY Tier 2 question, option table, or recommendation to the user:**
+
+1. Read the checkpoint file
+2. Check `synthesis_written` for the current item
+3. If `synthesis_written: false` → **STOP**. Do not present anything to the user. Read the files in `pending_reads`, write the synthesis to the appropriate synthesis file, update `synthesis_written: true` in the checkpoint, THEN proceed
+4. If `synthesis_written: true` → proceed with user-facing output
+
+This gate catches the exact failure mode: context truncation drops the synthesis step, the agent pattern-matches "STK-04 is next" from the summary, and jumps straight to asking the user generic questions.
+
+## Shard-specific checkpoint patterns
+
+### create-prd-stack
+
+- `current_item` format: `{Axis Name} (STK-{NN})`
+- `items_completed` tracks each axis
+- `pending_reads` populated from Ideation Relevance Index per-axis
+- Checkpoint updated at per-axis flow step 9 (move to next axis)
+
+### create-prd-design-system
+
+- `current_item` format: `{Decision Name} (DS-{NN})`
+- 7 decisions tracked: Navigation Paradigm, Layout Grid, Page Archetypes, Component Hierarchy, Motion System, Data Density, State Design Language
+- `pending_reads` populated from heavy domain files
+
+### create-prd-architecture / security / compile
+
+- `current_item` format: `{Section Name}`
+- Tracks major sections (e.g., "System Components", "Data Strategy", "Security Model")
+- `pending_reads` populated from relevant ideation domains per section
+
+## Cleanup
+
+The parent orchestrator (`create-prd.md`) deletes or archives the checkpoint file after Step E (quality gate) passes. The file is a process artifact — once the PRD is compiled, it has no further value.
+
+The synthesis files in `prd-working/` are kept as audit trail.

package/template/.claude/skills/prd-templates/references/write-verification-protocol.md

@@ -0,0 +1,57 @@
+# Write Verification Protocol
+
+**Purpose**: Every file write MUST be verified by reading the file back. This protocol eliminates the ~18 instances of "write the completed section" without verification.
+
+---
+
+## Procedure
+
+### 1. Write
+
+Write the content to the target file at the specified section.
+
+### 2. Read Back
+
+Immediately after writing, read the target file. Locate the section header that was just written.
+
+### 3. Verify
+
+Check ALL of these conditions:
+
+- [ ] The section header exists in the file
+- [ ] The section content is non-empty (not just a header with no body)
+- [ ] The content matches what was intended (key fields present, no truncation)
+
+### 4. Handle Failure
+
+**If ANY check fails:**
+
+1. Log: "Write verification failed for `[file]` section `[section]`."
+2. Retry the write once.
+3. Read back again and re-verify.
+4. If second attempt fails → **STOP**: "Unable to write `[section]` to `[file]` after 2 attempts. Investigate before proceeding."
+
+### 5. Confirm
+
+After successful verification, log: `Write verified: [file] § [section]`
+
+---
+
+## When to Use
+
+Any workflow step that says:
+- "Write the completed [section]"
+- "Write [content] to [file]"
+- "Update [file] with [content]"
+- "Append [content] to [file]"
+
+MUST follow this protocol. There are no exceptions. A write instruction without read-back verification is an enforcement failure.
+
+---
+
+## Scope
+
+This protocol applies to **spec and instruction file writes** — the documents that drive downstream pipeline behavior. It does NOT apply to:
+- Progress tracking file writes (those have their own verification in the completion checklist)
+- Temporary/scratch files
+- Audit report writes (those are progressive and self-verifying)

package/template/.claude/skills/prompt-engineer/SKILL.md

@@ -0,0 +1,203 @@
+---
+name: prompt-engineer
+description: "Transforms user prompts into optimized prompts using established frameworks (RTF, RISEN, Chain of Thought, RODES). Analyzes intent, selects framework, and produces structured, ready-to-use prompts."
+version: 2.0.0
+source: self
+date_added: "2026-02-27"
+date_rewritten: "2026-03-14"
+---
+
+# Prompt Engineering
+
+Transform vague or unstructured prompts into highly effective, framework-backed prompts that maximize AI output quality.
+
+## When to Use
+
+- User provides a vague or generic prompt ("help me code Python")
+- User has a complex idea but struggles to articulate it clearly
+- User asks "create a prompt for..." or "how do I ask AI to..."
+- Task requires step-by-step reasoning (debugging, analysis, design)
+- User wants to improve an existing prompt's effectiveness
+
+## When NOT to Use
+
+- User's prompt is already clear and specific
+- Simple factual questions ("what is X?")
+- During pipeline workflows that have their own prompting structure
+
+## Operating Mode
+
+Work silently — no framework jargon in the output. The user gets a polished prompt, not a lecture on prompt engineering theory.
+
+---
+
+## Workflow
+
+### 1. Analyze Intent
+
+Read the raw prompt and detect:
+
+| Dimension | Options |
+|-----------|---------|
+| **Type** | Coding, writing, analysis, design, learning, planning, creative |
+| **Complexity** | Simple (one-step), moderate (multi-step), complex (reasoning needed) |
+| **Clarity** | Clear intent vs. ambiguous/vague |
+| **Domain** | Technical, business, creative, academic |
+
+Identify implicit requirements:
+- Does the user need examples?
+- Is the output format specified?
+- Are there constraints (time, scope, resources)?
+- Is this exploratory or execution-focused?
+
+### 2. Clarify If Needed
+
+- **0 questions** if intent is clear (most cases)
+- **1-2 questions max** if critical information is ambiguous
+- **Never ask** about framework selection — that's your job
+
+### 3. Select Framework
+
+| Task Type | Framework | Why |
+|-----------|-----------|-----|
+| Role-based tasks (act as expert) | **RTF** (Role-Task-Format) | Clear role + task + output format |
+| Step-by-step reasoning (debugging, analysis) | **Chain of Thought** | Forces explicit reasoning steps |
+| Multi-phase projects (systems, deliverables) | **RISEN** (Role, Instructions, Steps, End goal, Narrowing) | Comprehensive structure |
+| Complex design/architecture | **RODES** (Role, Objective, Details, Examples, Sense check) | Balances detail with validation |
+| Summarization/synthesis | **Chain of Density** | Iterative compression to essentials |
+| Communication (reports, presentations) | **RACE** (Role, Audience, Context, Expectation) | Audience-aware messaging |
+| Goal-setting (OKRs, planning) | **CLEAR** (Collaborative, Limited, Emotional, Appreciable, Refinable) | Actionable goals |
+
+**Blending**: Combine 2 frameworks when a task spans types. Example: architecture design → RODES + Chain of Thought.
+
+**Selection happens silently** — never explain framework choice to the user.
+
+### 4. Generate Prompt
+
+Build the optimized prompt using the selected framework(s):
+
+**Structure rules:**
+- Start with a clear role definition
+- State the objective in one sentence
+- Break complex tasks into numbered steps
+- Include output format specification
+- Add a validation/sense-check instruction for complex tasks
+- Keep the prompt self-contained (no external context needed)
+
+**Quality checks before presenting:**
+- [ ] Prompt is self-contained
+- [ ] Task is specific and measurable
+- [ ] Output format is clear
+- [ ] No ambiguous language
+- [ ] Appropriate detail for task complexity
+- [ ] Language matches user's language
+
+### 5. Present
+
+Present the optimized prompt in a clean markdown code block. No meta-commentary, no framework explanation.
+
+---
+
+## Examples
+
+### Vague Input → RTF
+
+**User**: "help me write better code"
+
+**Output**:
+```
+Role: You are a senior software engineer conducting a code review.
+
+Task: Review the code I provide and identify issues across these dimensions:
+1. Readability — naming, structure, comments
+2. Correctness — logic errors, edge cases, off-by-one errors
+3. Performance — unnecessary allocations, O(n²) where O(n) exists
+4. Security — injection risks, data exposure, input validation
+5. Maintainability — coupling, cohesion, testability
+
+Format: For each issue found, provide:
+- Location (file/line if applicable)
+- Category (readability/correctness/performance/security/maintainability)
+- Current code
+- Suggested improvement with explanation
+- Severity (critical/warning/suggestion)
+```
+
+### Complex Input → RODES + Chain of Thought
+
+**User**: "I need to build a recommendation system using purchase history and user preferences"
+
+**Output**:
+```
+Role: You are a senior ML engineer specializing in recommendation systems.
+
+Objective: Design a product recommendation system combining user purchase history, stated preferences, and behavioral signals.
+
+Details:
+- Input sources: transaction logs, preference surveys, browsing behavior
+- Algorithm tradeoffs: collaborative filtering vs. content-based vs. hybrid
+- Performance targets: recommendations served in <200ms, updated hourly
+- Scale: handle 100K+ users with sparse interaction matrices
+
+Approach this step-by-step:
+1. Analyze data sources and their signal quality
+2. Propose 2-3 algorithm approaches with tradeoff analysis
+3. Design the data pipeline (ingestion → processing → serving)
+4. Define evaluation metrics (precision, recall, diversity, novelty)
+5. Outline a phased implementation roadmap
+
+Examples: Include pseudocode for the core recommendation logic, a data flow diagram, and sample API response structure.
+
+Sense check: Verify the solution balances personalization with discovery, handles cold-start problems for new users, and scales to production load.
+
+Output: Technical design document with architecture diagrams, algorithm justification, and implementation roadmap.
+```
+
+### Debugging → Chain of Thought
+
+**User**: "my code isn't working, needs debugging"
+
+**Output**:
+```
+You are an expert debugger.
+
+Task: Debug the code I provide using systematic analysis.
+
+Step-by-step approach:
+1. Read the code and identify its intended purpose
+2. Identify the error or unexpected behavior
+3. Trace variable states through execution
+4. Locate the root cause
+5. Propose a fix with explanation
+6. Suggest preventive measures
+
+For each step, show your reasoning:
+- What you're checking
+- What you found
+- Why it matters
+
+Output format:
+- **Issue**: [Describe the bug]
+- **Root cause**: [Why it's happening]
+- **Fix**: [Corrected code with inline comments]
+- **Prevention**: [How to avoid this in the future]
+
+Include a minimal working example to verify the fix.
+```
+
+---
+
+## Rules
+
+**NEVER:**
+- Explain which framework was selected or why
+- Generate generic, one-size-fits-all prompts
+- Ask more than 2 clarifying questions
+- Include meta-commentary ("This prompt uses...", "Note that...")
+
+**ALWAYS:**
+- Analyze intent before generating
+- Select framework based on task type and complexity
+- Include output format specification
+- Present in a clean code block
+- Match the user's language (English → English, etc.)