cfsa-antigravity 3.0.2 → 3.1.0

package/template/.codex/skills/create-prd-architecture/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: create-prd-architecture
+description: Define system architecture, error architecture, and data strategy with map guards and ideation context reload
+parameters:
+  - name: strict_map_guard
+    type: boolean
+    required: false
+    description: If true, fail immediately when required map cells are missing
+---
+
+## Overview
+
+
+## Prerequisites
+
+1. Stack decisions completed
+2. Required map cells available for Hosting, ORMs, Databases
+
+## Step-by-Step
+
+### Step 0 — Map guard and context reload
+
+1. Validate required map cells from `.codex/instructions/tech-stack.md`.
+2. If any required cell is empty: stop and request map completion.
+3. Read ideation context sources (index, constraints, global/domain CX, domain indexes or digest).
+4. Resume/initialize checkpoint.
+
+### Step 1 — System architecture section
+
+Design and confirm:
+1. Component diagram
+2. Data flow lifecycle
+3. Deployment topology
+4. API surface
+5. Deployment strategy
+6. Surface interconnection (when multi-surface)
+7. Shared domain boundary ownership
+
+Write confirmed `## System Architecture` to `.memory/wiki/specs/architecture-draft.md` immediately.
+
+### Step 2 — Error architecture section (hard gate)
+
+1. Run error architecture interview.
+2. Confirm all five required decisions.
+3. Write `## Error Architecture` with five sub-sections and canonical envelope example.
+
+### Step 3 — Data strategy section
+
+1. Run data strategy interview using database/ORM skill guidance.
+2. Define placement, schema approach, query patterns, migrations, PII boundaries.
+3. For multi-surface: define ownership and sync protocol.
+4. Run cross-store entity consistency pass.
+5. Write confirmed `## Data Strategy` to architecture draft.
+
+### Step 4 — Data placement document
+
+Create `.memory/wiki/specs/data-placement-strategy.md` from template using locked data decisions.
+
+## Completion Checklist
+
+- [ ] Map guard passed
+- [ ] Ideation context reloaded
+- [ ] System architecture written and confirmed
+- [ ] Error architecture written and confirmed
+- [ ] Data strategy written and confirmed
+- [ ] Cross-store consistency captured
+- [ ] data-placement-strategy.md created
+- [ ] Checkpoint updated
+
+## Next Steps
+
+- Run `create-prd-security`

package/template/.codex/skills/create-prd-compile/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: create-prd-compile
+description: Compile architecture draft into dated architecture design and engineering standards with rubric-complete quality gates
+parameters:
+  - name: output_date
+    type: string
+    required: false
+    description: Optional date override for architecture output filename (YYYY-MM-DD)
+---
+
+## Overview
+
+
+## Prerequisites
+
+1. Security shard completed
+2. `.memory/wiki/specs/architecture-draft.md` exists with required sections
+3. Required map cells available for Unit Tests, E2E Tests, CI/CD
+
+## Step-by-Step
+
+### Step 0 — Map guard and checkpoint
+
+1. Validate required map cells in tech stack map.
+2. Resume/initialize checkpoint state for compile shard.
+
+### Step 1 — Development methodology
+
+1. Define and confirm:
+   - contract-first approach
+   - TDD discipline
+   - vertical slices
+   - spec layer flow
+   - quality gates
+2. Write `## Development Methodology` to architecture draft immediately.
+
+### Step 2 — Phasing strategy (with ideation reload)
+
+1. Reload ideation context for Must domains, domain depth, and CX dependencies.
+2. Build dependency-ordered phases with infrastructure verification gates.
+3. Confirm phase ordering and feasibility.
+4. Write `## Phasing Strategy` to architecture draft.
+
+### Step 3 — Lock directory structure
+
+1. Generate canonical directory tree from locked stack decisions.
+2. Present architecture separation table.
+3. Require explicit approval.
+4. Trigger bootstrap keys for project structure outputs.
+5. Write `## Directory Structure` section to architecture draft.
+
+### Step 4 — Compile final architecture document
+
+1. Validate required sections exist in architecture draft.
+2. Compile to `.memory/wiki/specs/YYYY-MM-DD-architecture-design.md`.
+3. Ensure section depth is implementation-ready.
+
+### Step 5 — Performance budgets and engineering standards
+
+1. Run performance budget interview for all applicable axes.
+2. Write confirmed budgets to `.memory/wiki/specs/ENGINEERING-STANDARDS.md` immediately.
+3. Compile full engineering standards with no unresolved placeholders.
+
+### Step 6 — Rubric gate and review request
+
+1. Run architecture rubric self-check (all dimensions).
+2. Resolve any warning/fail dimensions before review request.
+3. Present final architecture design + engineering standards for approval.
+4. Stop and wait for explicit user approval.
+
+## Completion Checklist
+
+- [ ] Map guard passed
+- [ ] Development methodology written
+- [ ] Phasing strategy written
+- [ ] Directory structure locked and written
+- [ ] Dated architecture-design document compiled
+- [ ] ENGINEERING-STANDARDS.md compiled
+- [ ] Rubric self-check all green
+- [ ] Review request sent and workflow paused
+
+## Next Steps
+
+After explicit approval, the only valid next command is:
+- `/audit-ambiguity architecture`

package/template/.codex/skills/create-prd-design-system/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: create-prd-design-system
+description: Lock seven design-system decisions from ideation workflows and persist design-system.md incrementally
+parameters:
+  - name: surfaces
+    type: array
+    required: false
+    description: Optional explicit surfaces override; defaults to ideation constraints
+---
+
+## Overview
+
+
+## Prerequisites
+
+1. Stack shard completed
+2. Design direction confirmed in brand-guidelines context
+3. Ideation constraints and structure map available
+
+## Step-by-Step
+
+### Step 0 — Prerequisite and context load
+
+1. Verify design direction placeholders are resolved.
+2. Read engagement tier from ideation index.
+3. Read constraints, ideation structure map, heavy domains, and CX files.
+4. Enforce stop gate: must read at least one domain index/deep-dive beyond ideation index.
+
+### Step 1 — Checkpoint resumption
+
+1. Resume or initialize design-system shard checkpoint.
+2. Track completion state per decision.
+
+### Step 2 — Per-decision synthesis and locking (7 decisions)
+
+For each decision below:
+1. Write cited ideation synthesis (2-4 bullets) to `.memory/wiki/specs/architecture/prd-working/design-system-synthesis.md`.
+2. Enforce cite-or-stop gate (minimum one project-specific citation).
+3. Present options, trade-offs, recommendation.
+4. Confirm decision (tier-aware).
+5. Write corresponding section to `.memory/wiki/specs/design-system.md` immediately.
+
+Decisions:
+1. Navigation paradigm
+2. Layout grid
+3. Page archetypes
+4. Global component inventory
+5. Motion language
+6. Data density philosophy
+7. Global state design language
+
+### Step 3 — Completeness verification
+
+1. Validate all seven sections exist in `.memory/wiki/specs/design-system.md`.
+2. Ensure no placeholders or TBD values remain.
+3. Ensure global component inventory is usable as FE seed inventory.
+
+## Completion Checklist
+
+- [ ] Context and prerequisite gates passed
+- [ ] Checkpoint state updated
+- [ ] Seven synthesis sections written
+- [ ] Seven design-system decisions confirmed
+- [ ] design-system.md written progressively
+- [ ] Completeness verification passed
+
+## Next Steps
+
+- Run `create-prd-architecture`

package/template/.codex/skills/create-prd-security/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: create-prd-security
+description: Define security, attack surface, integration, and observability architecture with compliance escalation
+parameters:
+  - name: strict_map_guard
+    type: boolean
+    required: false
+    description: If true, fail immediately when Security/Auth map cells are missing
+---
+
+## Overview
+
+
+## Prerequisites
+
+1. Architecture shard completed with component/data strategy context
+2. Required map cells available for Security and Auth
+
+## Step-by-Step
+
+### Step 0 — Map guard and context reload
+
+1. Validate Security and Auth entries in cross-cutting map section.
+2. Reload ideation context: personas, constraints/compliance, domain role matrices, CX trust boundaries.
+3. Resume/initialize checkpoint.
+
+### Step 1 — Security model with compliance escalation
+
+1. Define authentication and authorization scope (or documented no-auth scope when applicable).
+2. Define data protection, validation, age restrictions/compliance, rate limiting, CSP/CORS, code signing.
+3. Escalate minors/payments/health/government constraints to top-level architectural sections when applicable.
+4. Confirm decisions and write `## Security Model` to architecture draft immediately.
+5. Trigger bootstrap for newly locked security keys when required.
+
+### Step 2 — Attack surface review
+
+1. Run universal and surface-specific attack surface checks.
+2. Confirm with user.
+3. Write `## Security — Attack Surface` section.
+
+### Step 3 — Integration points
+
+1. If zero external integrations, write explicit no-integration statement.
+2. Otherwise document each integration: provided capability, failure mode, fallback, cost model.
+3. Write `## Integration Points` section.
+
+### Step 4 — Observability architecture
+
+1. Run observability decision interview: logging, tracing, alerting, dashboards, retention.
+2. Confirm decisions and trigger required bootstrap keys.
+3. Write `## Observability Architecture` section.
+
+## Completion Checklist
+
+- [ ] Map guard passed
+- [ ] Ideation context reloaded
+- [ ] Security model locked and written
+- [ ] Compliance escalations documented where required
+- [ ] Attack surface section written
+- [ ] Integration points section written
+- [ ] Observability section written
+- [ ] Checkpoint updated
+
+## Next Steps
+
+- Run `create-prd-compile`

package/template/.codex/skills/create-prd-stack/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: create-prd-stack
+description: Execute constraint-first tech stack decisioning with per-axis ideation synthesis and progressive bootstrap triggers
+parameters:
+  - name: strict
+    type: boolean
+    required: false
+    description: If true, fail when any decision axis remains unresolved
+---
+
+## Overview
+
+
+## Prerequisites
+
+1. `.memory/wiki/specs/ideation/ideation-index.md` exists
+2. `.memory/wiki/specs/ideation/meta/constraints.md` exists and includes `## Project Surfaces`
+
+## Step-by-Step
+
+### Step 1 — Checkpoint resumption
+
+1. Use workflow checkpoint protocol at `.memory/wiki/specs/architecture/prd-working/workflow-state.md`.
+2. Resume if active shard matches; otherwise initialize fresh shard checkpoint.
+
+### Step 2 — Constraint-first discovery
+
+1. Read constraints and ideation index for structural classification + engagement tier.
+2. Build and present constraints map:
+   - hard constraints
+   - surface constraints
+   - soft constraints
+3. Read per-axis constraint question references before options.
+
+### Step 3 — Build ideation relevance index (mandatory)
+
+1. Create `.memory/wiki/specs/architecture/prd-working/ideation-relevance-index.md`.
+2. Map each decision axis to relevant domain/deep-dive/CX files.
+3. Enforce stop gate: every axis must have at least one relevant ideation file.
+
+### Step 4 — Per-axis stack decisions
+
+For each applicable axis:
+1. Read all files listed for that axis in relevance index.
+2. Answer Tier 1 constraint questions from ideation evidence.
+3. Append axis synthesis (3-5 cited bullets) to `.memory/wiki/specs/architecture/prd-working/stack-synthesis.md`.
+4. Enforce cite-or-stop gate (minimum two project-specific citations).
+5. Ask Tier 2 user-facing questions.
+6. Present filtered options + recommendation.
+7. Confirm decision (tier-aware).
+8. Trigger progressive bootstrap for confirmed key(s).
+9. Verify bootstrap result and update checkpoint state.
+
+### Step 5 — Persistence map interview
+
+1. Run database persistence-map methodology from database-schema-design skill.
+2. Confirm each required store.
+3. Trigger bootstrap + verification per confirmed store.
+
+### Step 6 — Design direction and tooling
+
+1. Run design direction decision flow.
+2. Trigger bootstrap for DESIGN_DIRECTION.
+3. Confirm development tooling axes and trigger bootstrap for tooling keys.
+
+### Step 7 — Decision persistence
+
+1. Append confirmed decisions to `.memory/wiki/specs/architecture-draft.md` as they are locked.
+2. Ensure no unresolved `TBD` values remain in this shard output.
+
+## Completion Checklist
+
+- [ ] Checkpoint started/resumed
+- [ ] Constraints map completed
+- [ ] Ideation relevance index written
+- [ ] Per-axis synthesis completed for all axes
+- [ ] Progressive bootstrap fired and verified per confirmed key
+- [ ] Persistence map interview completed
+- [ ] Design direction and tooling decisions completed
+- [ ] Stack decisions written to architecture draft
+
+## Next Steps
+
+- Run `create-prd-design-system`

package/template/.codex/skills/cross-layer-consistency/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: cross-layer-consistency
+description: Systematic methodology for verifying that IA, BE, and FE specification layers are mutually consistent. Covers coverage matrices, field mapping checks, error code propagation, access control consistency, and data contract drift detection.
+---
+
+# Cross-Layer Consistency
+
+This skill provides the systematic consistency verification pass run by `audit-ambiguity-execute`, `remediate-pipeline-execute`, `propagate-decision-scan`, and `evolve-feature-cascade`, and its output is a set of labeled consistency issues with layer attribution.
+
+## When to Use
+
+- After all three spec layers (IA, BE, FE) have at least one document written
+- As part of every audit, every remediation, every decision propagation, and every feature evolution cascade
+- As a standalone pre-gate check before advancing any pipeline stage
+
+## Instructions
+
+### 1. IA → BE Coverage Matrix
+
+Open `.memory/wiki/specs/ia/index.md` to enumerate all IA shards. For each shard, read its data model and state transition sections. Then open `.memory/wiki/specs/be/` and verify:
+
+- Every IA data model entity has a corresponding BE spec section describing its schema, storage contract, and CRUD operations.
+- Every IA state transition has a corresponding BE endpoint that drives it.
+- Every IA user action (described in the interactions section) has a corresponding API contract in the BE spec.
+
+Build a coverage table:
+
+| IA Shard | IA Section | BE Spec Section | Status |
+|----------|-----------|-----------------|--------|
+| [name]   | [section] | [BE section]    | ✅ / ❌ |
+
+Document each gap as:
+
+```
+COVERAGE GAP: IA shard [name] § [section] → no corresponding BE spec section found.
+```
+
+### 2. BE → FE Field Mapping Check
+
+For every BE endpoint documented in `.memory/wiki/specs/be/`, enumerate all response fields. For each field, verify it appears in `.memory/wiki/specs/fe/` — in a component prop definition, a display element, a table column, or an explicit "field not rendered" exclusion.
+
+Then for each FE component, verify every input prop maps to a BE request field.
+
+Build a mapping table:
+
+| BE Endpoint | Field | FE Spec Location | Status |
+|-------------|-------|-------------------|--------|
+| [endpoint]  | [field] | [FE location]   | ✅ / ❌ |
+
+Document each gap as:
+
+```
+MAPPING GAP: BE endpoint [name] field [field] → not referenced in FE spec.
+```
+
+### 3. Error Code Consistency Cross-Reference
+
+Build an error code table across layers: for every HTTP status code and application error type defined in BE specs, create a row. Then for each row, identify the FE spec location that handles it (error boundary, toast handler, inline error state, retry logic).
+
+| BE Endpoint | Error Code | FE Handler | FE Spec Location | Status |
+|-------------|-----------|------------|-------------------|--------|
+| [endpoint]  | [code]    | [handler]  | [location]        | ✅ / ❌ |
+
+Any BE error code with no corresponding FE entry is a gap. Document as:
+
+```
+CONSISTENCY ISSUE: BE § [endpoint] error [code] ↔ FE — no handling found — remediation: add [code] handler to [FE spec section].
+```
+
+### 4. Access Control Propagation Check
+
+For every access control rule defined in IA shards (role-resource-operation triplets), verify the rule appears in both:
+
+- **BE**: as a middleware guard, route-level permission check, or explicit authorization step in the endpoint contract.
+- **FE**: as a conditional render, route guard, or disabled state on the triggering UI element.
+
+A rule missing from either layer is a gap. Document as:
+
+```
+CONSISTENCY ISSUE: IA § [access control section] permission [role→resource:operation] ↔ [BE or FE] — not found — remediation: add guard to [target layer § section].
+```
+
+### 5. Data Contract Drift Detection
+
+When invoked in the context of a schema change (e.g., after `evolve-contract` or a `propagate-decision` run), scan all files under `.memory/wiki/specs/` for references to the changed type, field name, or validation rule. Check for:
+
+- Field name string matches
+- Type annotation references
+- Validation rule references
+
+For each file that references the old definition and has not been updated, document as:
+
+```
+CONSISTENCY ISSUE: [source layer] § [section] ↔ [target file] § [section] — [field/type] changed in source but not reflected in target — remediation: update [target] to match [source].
+```
+
+### 6. Documenting Inconsistencies
+
+All consistency issues must be written using this exact format:
+
+```
+CONSISTENCY ISSUE: [source layer] § [section] ↔ [target layer] § [section] — [what is inconsistent] — [remediation: update [target] to match [source] OR raise for user decision]
+```
+
+- **Source layer** is the authoritative layer (the one that should not change).
+- **Target layer** is the one that needs updating.
+- When it is unclear which layer is authoritative, write `raise for user decision` as the remediation and present both versions to the user. Never silently pick one.
+
+## Anti-Patterns
+
+- **One-direction-only checking** — Checking only one direction of the matrix (IA→BE but not BE→IA). Coverage gaps exist in both directions.
+- **Skipping the error code table** — Skipping the error code table because "the FE will just show a generic error." Every BE error code must have an explicit FE handling specification.
+- **Treating access control propagation as optional** — Treating access control propagation as optional when the spec "looks simple." Missing FE route guards are a security gap, not a style preference.
+
+## Related Skills
+
+- **`resolve-ambiguity`** — Hand off to `resolve-ambiguity` when a consistency issue cannot be resolved by simply updating the target layer to match the source. Specifically: when both layers present plausible but conflicting definitions and it is unclear which is authoritative, or when the inconsistency reveals a gap that requires new information from the user. This skill detects *what is inconsistent*; `resolve-ambiguity` determines *what the correct answer should be* through its tiered information-gathering methodology.