cfsa-antigravity 3.0.2 → 3.1.0

package/template/.codex/skills/plan-phase-write/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: plan-phase-write
+description: Derive slices from specs, order by dependencies, write acceptance criteria with citations, and finalize phase/progress artifacts
+parameters:
+  - name: phase
+    type: string
+    required: false
+    description: Optional explicit phase number override
+---
+
+## Overview
+
+
+## Prerequisites
+
+1. Preflight shard passed
+2. Scope sources available (architecture phasing + BE/FE indexes)
+
+## Step-by-Step
+
+### Step 1 — Read phase scope
+
+1. Read architecture design phasing section.
+2. Read BE index to determine in-scope specs.
+
+### Step 2 — Spec-anchored slice derivation
+
+1. Derive candidate slices from FE interaction specification user flows.
+2. Map each flow to BE endpoints via source map.
+3. Group only when strict dependency criteria are met.
+4. Size slices (S/M/L).
+5. Enforce L-slice review/split decision before ordering.
+6. Enforce slice count sanity gates (warn at 16–25, hard stop >25).
+
+### Step 3 — Spec coverage verification gate
+
+1. Build BE endpoint coverage table (covered/uncov/deferred).
+2. Build FE component coverage table.
+3. Require every endpoint/component to be assigned or explicitly deferred before proceeding.
+4. Update feature-ledger slice assignment when ledger exists.
+5. Add split-companion context notes for letter-suffixed split groups.
+
+### Step 4 — Dependency ordering and infrastructure gates
+
+1. Order slices by dependency.
+2. Enforce infrastructure-first rules and `/setup-workspace` prerequisite gate.
+3. Add explicit `/verify-infrastructure` hard-gate checkpoints in the phase plan.
+4. Incorporate parallelization guidance while preserving TDD order constraints.
+
+### Step 5 — Acceptance criteria writing (write-as-you-go)
+
+1. For each slice, write acceptance criteria using operational template.
+2. Every criterion must include source citation (`[BE §..]`, `[FE §..]`, `[IA §..]`).
+3. Append each completed slice progressively to `phase-N-draft.md`.
+
+### Step 6 — Finalize and generate progress artifacts
+
+1. Finalize `phase-N.md` from draft source.
+2. Generate progress files via progress-generation protocol.
+3. Run bootstrap/map completeness gate for planning-critical categories.
+
+### Step 7 — Graph refresh, review request, and constrained next step
+
+1. Run `memory_compile` after finalizing phase artifacts so graph/hubs reflect the latest planning state.
+2. Present phase plan + progress artifacts for approval.
+3. Include graph refresh confirmation.
+4. Stop until explicit approval.
+5. Recommend only `/implement-slice` as next command after approval.
+
+## Completion Checklist
+
+- [ ] scope and in-scope specs read
+- [ ] slices derived from FE/BE sources
+- [ ] coverage gate passed
+- [ ] dependency ordering complete with infra gates
+- [ ] acceptance criteria written with citations
+- [ ] phase draft and final plan written
+- [ ] progress files generated
+- [ ] spec graph refreshed via `memory_compile`
+- [ ] review requested with constrained next step
+
+## Next Steps
+
+After explicit approval:
+- `/implement-slice`

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

@@ -0,0 +1,107 @@
+---
+name: prd-templates
+description: "Document templates for all pipeline output documents — specs, indexes, reports, and strategy docs. Use when any workflow needs to produce a structured document."
+category: templates
+risk: none
+source: self
+date_added: "2026-02-28"
+---
+
+# PRD Templates
+
+Canonical markdown templates for all pipeline output documents. Workflows reference these templates instead of inlining them — the template defines structure, the workflow fills content.
+
+## When to Use This Skill
+
+- During any workflow step that produces a structured document
+- When writing specs (BE, FE), indexes, reports, or strategy documents
+- During classification steps that seed spec file stubs
+
+## Conventions
+
+**Dated File Convention**: Compiled artifacts (e.g., `architecture-design.md`, `data-placement-strategy.md`, `ENGINEERING-STANDARDS.md`, audit reports) are always prefixed with `YYYY-MM-DD-`. Any workflow reading these files must use a glob pattern (e.g., `.memory/wiki/specs/*-architecture-design.md`). See `docs/kit-architecture.md` Section 3 — Dated File Convention for the full rule and table. Note: `ideation-index.md` and `vision.md` are NOT dated — they are living documents updated throughout ideation.
+
+## How to Use
+
+1. Read the appropriate template from `references/`
+2. Fill each section with content gathered during prior workflow steps
+3. Apply the depth rule: every section should have ≥200 words for architecture docs; no section should use TBD or placeholder values
+
+## Reference Files
+
+| Template | File | Used By |
+|----------|------|---------|
+| Architecture Design | `references/architecture-design-template.md` | `/create-prd-compile` Step 10 |
+| Engineering Standards | `references/engineering-standards-template.md` | `/create-prd-compile` Step 11 |
+| Vision Document | `references/vision-template.md` | `/ideate-validate` Step 11 |
+| BE Spec + Seed Stub | `references/be-spec-template.md` | `/write-be-spec-write` Step 7, `/write-be-spec-classify` |
+| FE Spec + Seed Stub | `references/fe-spec-template.md` | `/write-fe-spec-write` Step 6, `/write-fe-spec-classify` |
+| Data Placement Strategy | `references/data-placement-template.md` | `/create-prd-architecture` Step 5 |
+| Design System Decision Options | `references/design-system-decisions.md` | `/create-prd-design-system` Step 1 (option menus + output template); downstream: `write-fe-spec-classify` Step 0.75 prerequisite check |
+| Infrastructure Report | `references/infrastructure-report-template.md` | `/verify-infrastructure` Steps 0.6, 8 |
+| Decomposition (shards + indexes) | `references/decomposition-templates.md` | `/decompose-architecture-structure` Steps 5-9 |
+| Operational (slices, remediation, skills, sync) | `references/operational-templates.md` | `/plan-phase`, `/remediate-pipeline-assess`, `/bootstrap-agents-provision`, `/sync-kit` |
+
+## Depth Standards
+
+> **Template depth rule**: Section headings in templates are MINIMUM headings, not maximum content. Each section must contain the full detail gathered during prior steps. If a section is under 200 words, it's almost certainly too shallow. Apply the two-implementer test: could a developer interpret this two different ways? If yes, add more detail.
+
+## Shard Seeding Procedure
+
+Run this procedure when filling the `## Features` section of each shard skeleton during `/decompose-architecture-structure`.
+
+### Source
+
+Read `.memory/wiki/specs/ideation/ideation-index.md` — specifically the `## Structural Classification` and `## Structure Map` sections.
+
+- **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 `.memory/wiki/specs/ideation/surfaces/{surface-name}/` (surface-exclusive) or `.memory/wiki/specs/ideation/domains/` (shared).
+
+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
+
+Extract every Level-1 sub-feature as a concrete capability a user would recognise, written in actor + goal format with primary data noted.
+
+**Example:** `"Creator can upload a video → primary data: media asset"`
+
+Do NOT use architecture-level headlines or implementation details.
+
+### Grouping Rule
+
+List sub-features as bullet points in the `## Features` section. Group by functional area if the ideation content suggests natural groupings.
+
+### `[THIN — review with user]` Fallback Rule
+
+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 (create a domain folder if needed)
+
+### Directory Example
+
+Seeded skeletons always live in the flat `.memory/wiki/specs/ia/` directory — IA is shared across all surfaces. Multi-product projects add per-surface BE and FE directories only:
+
+**Single-surface:**
+```
+.memory/wiki/specs/ia/
+├── 00-infrastructure.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)
+├── ...
+```
+
+**Multi-product** (IA stays flat — only BE/FE get per-surface directories):
+```
+.memory/wiki/specs/ia/
+├── 00-infrastructure.md
+├── 01-operations.md         ← ## Features seeded from ideation/surfaces/desktop/01-operations/ (index + feature files)
+├── 02-device-history.md     ← ## Features seeded from ideation/domains/02-device-history/ (index + feature files)
+
+.memory/wiki/specs/be/desktop/       ← per-surface BE specs (inside be/)
+.memory/wiki/specs/fe/desktop/       ← per-surface FE specs (inside fe/)
+.memory/wiki/specs/be/               ← shared BE specs (pre-scaffolded, serves as shared surface)
+.memory/wiki/specs/fe/               ← shared FE specs (pre-scaffolded, serves as shared surface)
+```

package/template/.codex/skills/prd-templates/references/architecture-completeness-checklist.md

@@ -0,0 +1,28 @@
+# Architecture Completeness Checklist
+
+Apply after the architecture rubric self-check. All items must pass.
+
+## Feature Coverage
+- [ ] Every "Must Have" feature from `ideation-index.md` MoSCoW list has a home in the architecture
+
+## Security Coverage
+- [ ] Security model addresses all compliance constraints from `ideation/meta/constraints.md`
+- [ ] Compliance-heavy domains have their own top-level sections (not buried as sub-bullets)
+
+## Stack Coverage
+- [ ] All relevant skills installed for chosen stack
+
+## Standards Coverage
+- [ ] Validation command in Engineering Standards matches `AGENTS.md` validation command
+
+## Multi-Surface (if applicable)
+- [ ] Sync strategy defined
+- [ ] Data ownership clear
+- [ ] Conflict resolution specified
+
+## Cross-Platform (if applicable)
+- [ ] Platform-specific considerations documented for each target OS
+
+## Design System
+- [ ] Design system document exists at `.memory/wiki/specs/design-system.md`
+- [ ] All seven decision areas are filled (no placeholders)

package/template/.codex/skills/prd-templates/references/architecture-design-template.md

@@ -0,0 +1,88 @@
+# Architecture Design Template
+
+Use this template when compiling `.memory/wiki/specs/YYYY-MM-DD-architecture-design.md`.
+
+```markdown
+# [Project Name] — Architecture Design
+
+> **Ideation**: [link to ideation-index.md]
+> **Date**: YYYY-MM-DD
+> **Status**: Draft | Review | Approved
+> **Project Type**: [Single-surface: web/desktop/mobile/CLI/API | Multi-surface: list surfaces]
+
+## Tech Stack
+[Explicit decision for each applicable axis with rationale — not just the choice,
+but WHY this choice over alternatives, what trade-offs were accepted, and what
+constraints drove the decision. For multi-surface projects, organized by surface.]
+
+## System Architecture
+[Component diagram, data flow, deployment topology — every service named, every
+communication path documented, every failure mode identified. For multi-surface:
+include surface interconnection diagram and shared domain boundary.]
+
+## Data Strategy
+[Placement, schema design, query patterns, migrations — which data lives where
+and why, what the hot paths are, how schema evolves. For multi-surface: data
+ownership, sync protocol, conflict resolution.]
+
+## Error Architecture
+[Global error envelope with locked example JSON — all four fields defined with types. Error
+propagation chain per layer (DB → service → API handler → transport → client) — what is caught,
+logged, and exposed at each layer. Unhandled exception strategy — process-level catch, log fields,
+client response, alerting timeline. Client fallback contract per surface — offline mode decision,
+UI behaviour on network failure, retry strategy, timeout threshold. Error boundary strategy per
+applicable surface — boundary placement and fallback rendering.]
+
+## Security Model
+[Auth, authorization, validation, rate limits — every flow specified step-by-step,
+every permission rule scoped, every error case handled]
+
+## Compliance & Safety
+[If applicable — full depth on minors/payments/health/regulated domains.
+This section may be the largest in the document if compliance constraints
+are significant. Every account type, every consent flow, every content filter,
+every notification trigger, every audit requirement.]
+
+## API Design
+[Surface type, versioning, conventions — endpoint naming, request/response shapes,
+error format, pagination strategy. For multi-surface: shared API contract format.]
+
+## Integration Points
+[External services, failure modes, fallbacks, cost models — for each: what it
+provides, what happens when it's down, what the fallback is]
+
+## Observability Architecture
+[Logging strategy — library named, structured JSON (yes/no for prod), log levels per environment,
+PII field names that are never logged (named explicitly), log destination. Tracing strategy —
+service boundaries traced, sampling rate per environment, trace ID propagation to API clients.
+Alerting thresholds — error rate %, latency threshold + duration, queue depth warning, delivery
+mechanism named. Launch dashboards — minimum required panels named, tool named, owner named.
+Retention — log retention duration, trace retention duration, compliance alignment.]
+
+## Development Methodology
+[Contract-first, TDD, vertical slices, spec layers, quality gates — the full
+process, not just labels]
+
+## Phasing
+[Phase breakdown with feature allocation, dependency order, and timeline estimates.
+Each phase has explicit entry/exit criteria. For multi-surface: per-surface or
+cross-surface phasing strategy.]
+
+## Directory Structure
+[The approved source directory tree from Step 9.5, with one-line descriptions per directory.
+Includes: contracts directory path, test layout, build output path, surface subtrees for multi-surface projects.]
+
+## Architecture Separation
+[The concern/location/runtime table from Step 9.5 — maps each architectural concern to its
+directory and the runtime where it executes.]
+
+## Installed Skills
+[List of skills installed during this workflow with versions]
+
+## Decisions Log
+[Every decision made during this workflow with rationale — not just what was
+decided, but what alternatives were considered and why they were rejected]
+
+## Open Questions
+[Anything needing resolution before decomposition — with owner and deadline]
+```

package/template/.codex/skills/prd-templates/references/be-spec-classification.md

@@ -0,0 +1,41 @@
+# BE Spec Classification Guide
+
+Use when classifying an IA shard during `/write-be-spec-classify` Step 2.
+
+## Classification Types
+
+| Classification | Description | BE Spec Output | Detection Criteria |
+|---------------|-------------|----------------|-------------------|
+| **Feature domain** | Defines user interactions, data models, and API-facing behavior for a single cohesive domain | 1 BE spec | Has data model + user flows + access model that imply API endpoints |
+| **Multi-domain** | Covers multiple distinct backend sub-systems with independent APIs | N BE specs (split along sub-feature boundaries) | Section headers map to independent API surfaces; data models don't overlap; could be developed by different teams |
+| **Cross-cutting** | Defines shared patterns consumed by all feature specs (auth, API conventions, error handling) | 1 cross-cutting BE spec (`00-*`) | Content is about "how all endpoints work" not "what this feature does" |
+| **Structural reference** | Maps structure, naming, or routing without defining API behavior | 0 BE specs | No data model, no user flows, no endpoints — just reference tables |
+| **Composite** | Contains both a structural reference section AND feature behavior | Depends — feature portion may belong in another shard's BE spec | Look for cross-references pointing feature content to its owning domain |
+
+## Multi-Domain Split Heuristic
+
+Before classifying as multi-domain, build a **sub-feature endpoint inventory**:
+
+| Sub-feature | Expected endpoints | Data model(s) | Independent? |
+|-------------|-------------------|---------------|-------------|
+| [sub-feature] | `POST /api/...`, `GET /api/...` | [table/collection names] | [Yes/No] |
+
+**Split criterion**: Two or more independent groups each have their own data model and could be assigned to a different developer without coordination → split. Section header count alone is NOT the criterion — independence of data models and API surfaces is.
+
+## Endpoint Completeness Reconciliation Table
+
+Use during `/write-be-spec-write` Step 7 before writing spec sections:
+
+| Sub-feature | Expected endpoints | Specced? | Notes |
+|-------------|-------------------|----------|-------|
+| [sub-feature] | `POST /api/...` | ✅ | — |
+| [sub-feature] | `GET /api/...` | ❌ | [Deferred to Phase N — reason] |
+
+**Rule**: For every unspecced expected endpoint, either add it to the spec or add an explicit `[Deferred to Phase N — reason]` note. An empty Notes column for an unspecced endpoint is a spec failure.
+
+## Naming Convention
+
+- Same number prefix as the IA shard source
+- Kebab-case feature name
+- Multi-domain splits: append letter suffix (e.g., `09a-chat-api.md`, `09b-agent-flow-api.md`)
+- Cross-cutting specs: `00-` prefix (e.g., `00-api-conventions.md`)

package/template/.codex/skills/prd-templates/references/be-spec-template.md

@@ -0,0 +1,107 @@
+# BE Spec Template
+
+Use this template when writing BE specs to `.memory/wiki/specs/be/[NN-feature-name].md`.
+
+```markdown
+# [Feature] — Backend Specification
+
+> **IA Source**: [link to IA shard]
+> **Deep Dives**: [links to consumed deep dives, if any]
+> **Status**: Draft | Review | Complete
+
+## Split Group _(include only if this spec resulted from a split)_
+
+> **Split origin**: [IA shard that was split, e.g., `09-messaging`]
+> **Companion specs**: [sibling BE spec files, e.g., `09b-agent-flow-api.md`]
+> **Shared entities**: [data models shared across companions, e.g., `Message`, `Thread`]
+
+## IA Source Map
+
+[Which IA shard sections, deep dives, and cross-shard references
+inform each part of this BE spec. This is the traceability record
+that lets a reviewer verify nothing was missed or invented.]
+
+| BE Spec Section | IA Source | Section/Lines |
+|-----------------|----------|---------------|
+| API Endpoints | [primary-shard.md] | § User Flows |
+| Database Schema | [primary-shard.md] | § Data Model |
+| Middleware | [cross-ref-shard.md] | § Access Control (lines N–M) |
+| Error Handling | [primary-shard.md] | § Edge Cases |
+| [specific subsystem] | [deep-dive.md] | § Key Decisions |
+
+## API Endpoints
+## Request/Response Contracts ({{CONTRACT_LIBRARY}} schemas)
+## Database Schema
+## Middleware & Policies
+## Data Flow
+## Error Handling
+## Open Questions
+
+## Changelog
+
+| Date | Change | Workflow | Sections Affected |
+|------|--------|----------|-------------------|
+| [date] | Initial creation | /write-be-spec | All |
+```
+
+## Quality Gates Checklist
+
+Apply after writing every BE spec:
+
+- [ ] Every endpoint has a {{CONTRACT_LIBRARY}} request AND response schema
+- [ ] Every database table has defined fields, indexes, and permissions
+- [ ] Security constraints from IA shard reflected in middleware section
+- [ ] Error codes are specific (not generic 500s)
+- [ ] Rate limits specified per endpoint
+- [ ] Access control requirements mapped to middleware checks
+- [ ] Every deep dive key decision is reflected in the spec (not ignored)
+- [ ] Every cross-shard reference has been resolved (no dangling pointers)
+- [ ] IA Source Map is complete — no BE spec section lacks a traceable IA source
+- [ ] Testability criteria from IA shard reflected as performance targets
+
+## BE Spec Seed Stub
+
+Use when creating a spec file during classification:
+
+```markdown
+# [Feature] — Backend Specification
+
+> **IA Source**: [link to IA shard]
+> **Deep Dives**: [links, if any]
+> **Status**: Classifying
+
+## Classification
+- **Type**: [single-domain | multi-domain-split | cross-cutting | structural reference]
+- **IA Source**: [shard name]
+- **BE Spec(s) to produce**: [list]
+
+## Referenced Material Inventory
+[Primary shard, cross-refs with file + section + line numbers]
+```
+
+## FE Spec Seed Stub
+
+Use when creating a spec file during FE classification:
+
+```markdown
+# [Feature] — Frontend Specification
+
+> **BE Source**: [link to BE spec(s)]
+> **IA Source**: [link to IA shard]
+> **Status**: Classifying
+
+## Classification
+- **Type**: [feature spec | cross-cutting]
+- **BE Source(s)**: [list]
+- **IA Source**: [shard name]
+
+## Referenced Material Inventory
+[same format as BE classify stub]
+
+## Design Requirements (extracted from brand-guidelines)
+**Direction**: [confirmed direction]
+**Typography**: [extracted]
+**Colors**: [extracted]
+**Motion**: [extracted]
+**Anti-patterns**: [extracted]
+```

package/template/.codex/skills/prd-templates/references/bootstrap-verification-protocol.md

@@ -0,0 +1,50 @@
+# Bootstrap Verification Protocol
+
+**Purpose**: Every bootstrap invocation MUST be verified. This protocol replaces all inline "fire bootstrap" instructions with a hard-gated fire→verify→stop cycle.
+
+---
+
+## Procedure
+
+### 1. Fire
+
+Read `.codex/skills/bootstrap-agents/SKILL.md` and execute with the provided key(s).
+
+### 2. Verify
+
+After bootstrap returns, verify that the target was actually filled:
+
+| Key Type | Where to Verify | How to Verify |
+|----------|----------------|---------------|
+| Language/Framework/DB/ORM | Surface stack map in `.codex/instructions/tech-stack.md` | The cell for the provided key's surface row is no longer empty |
+| CI/CD, Hosting, Auth, Security | Cross-cutting section of surface stack map | The cell is no longer empty |
+| Design direction | `.codex/skills/brand-guidelines/SKILL.md` | `{{DESIGN_DIRECTION}}` no longer appears as literal text |
+| Project structure | `.codex/instructions/structure.md` | `{{PROJECT_STRUCTURE}}` no longer appears as literal text |
+| Dev tooling | `.codex/instructions/commands.md` | Template values are replaced with real commands |
+| New dependency skill | `.codex/skills/[skill-name]/SKILL.md` | The skill directory exists and `SKILL.md` is readable |
+
+### 3. Hard Gate
+
+> **HARD STOP** — If any verification check fails, do NOT proceed. Report to the user:
+>
+> "Bootstrap was invoked with `[KEY]=[VALUE]` but verification failed:
+> - Expected `[target file]` cell `[cell name]` to contain `[VALUE]`
+> - Actual: `[what was found — empty, still placeholder, etc.]`
+>
+> This is a bootstrap bug. Do not proceed until resolved."
+
+### 4. Log
+
+After successful verification, note in the current workflow step: `Bootstrap verified: [KEY]=[VALUE] → [target cell] confirmed filled.`
+
+---
+
+## When to Use
+
+Any workflow step that says:
+- "fire bootstrap"
+- "invoke `/bootstrap-agents`"
+- "execute bootstrap"
+- "read bootstrap-agents.md and execute"
+
+MUST follow this protocol. There are no exceptions. A bootstrap fire without verification is an enforcement failure.

package/template/.codex/skills/prd-templates/references/constraint-exploration.md

@@ -0,0 +1,41 @@
+# Constraint Exploration Questions
+
+Use during `/ideate-validate` Step 8 to explore constraints with the user. Write answers to `.memory/wiki/specs/ideation/meta/constraints.md`.
+
+## Core Constraint Categories
+
+1. **Budget** — Self-funded? VC-backed? Monthly infrastructure ceiling?
+2. **Timeline** — Launch target? Phased rollout?
+3. **Team** — Solo dev? Small team? Skill gaps?
+4. **Compliance** — GDPR, PCI, COPPA, HIPAA, SOC 2? Age restrictions?
+5. **Performance** — Expected scale (users, requests, data)? Latency requirements?
+6. **Surface classification validation** — Verify the structural classification from `ideation-index.md` (set in `ideate-extract` Step 1.3) still holds. Have any new surfaces been discovered during exploration? Has the project shape changed?
+
+## Deep Think Prompt
+
+> "Based on the product type and user personas, what constraints would I expect that haven't been mentioned? For example, does this product handle payments (PCI)? Does it serve minors (COPPA)? Does it store health data (HIPAA)?"
+
+## Tier-Specific Behavior
+
+| Tier | Behavior |
+|---|---|
+| **Interactive/Hybrid** | Present each constraint question to user, wait for answers. Write each confirmed constraint immediately. |
+| **Auto** | Self-interview using Deep Think. Write all answers with reasoning immediately. Mark each answer as `[AUTO-CONFIRMED]` for traceability. |
+
+## Success Metrics (Per Persona)
+
+For each persona, define concrete success metrics:
+- What metric proves this product solves the persona's problem?
+- What's the target number? (specific — not "good response times")
+- What's the measurement method?
+
+Write to `ideation-index.md` (or link to domain files where the metric applies).
+
+## Competitive Positioning
+
+If not already explored during `/ideate-discover`:
+- Name 2-4 direct competitors
+- For each: what they do well, where they fail, how we differentiate
+- What's the moat? (network effects, data, expertise, switching costs)
+
+Write to `.memory/wiki/specs/ideation/meta/competitive-landscape.md`.

package/template/.codex/skills/prd-templates/references/data-placement-template.md

@@ -0,0 +1,74 @@
+# Data Placement Strategy Template
+
+Use this template to create `.memory/wiki/specs/data-placement-strategy.md` during `/create-prd-architecture`.
+
+```markdown
+# Data Placement Strategy
+
+## N-Tier Model Responsibilities
+
+Define each tier in the system and what it is responsible for:
+
+| Tier | Responsibility | Examples |
+|------|---------------|----------|
+| [Client / Edge / API / Database / Cache / Object Storage / External Service] | [What this tier owns and manages] | [Specific technologies] |
+
+## Complete Data Placement Map
+
+For every data type in the system, specify its canonical owner:
+
+| Data Type | Canonical Owner | Stored Content | Encryption | Rationale |
+|-----------|----------------|----------------|------------|-----------|
+| [e.g., User profile] | [e.g., Database] | [Fields stored] | [at-rest / in-transit / both / none] | [Why this placement] |
+| [e.g., Session tokens] | [e.g., Cache] | [Token data] | [encryption approach] | [Why this placement] |
+| [e.g., Uploaded files] | [e.g., Object storage] | [File content + metadata] | [encryption approach] | [Why this placement] |
+
+## Security Boundaries
+
+For each tier, explicitly state what it stores AND what it does NOT store:
+
+| Tier | Stores | Does NOT Store |
+|------|--------|---------------|
+| [Client] | [e.g., UI state, cached display data] | [e.g., raw PII, API secrets, decryption keys] |
+| [Edge/CDN] | [e.g., static assets, cached public responses] | [e.g., user-specific data, PII] |
+| [API Server] | [e.g., request context, short-lived auth tokens] | [e.g., persistent user data, raw credentials] |
+| [Database] | [e.g., user records, PII (encrypted)] | [e.g., API secrets, session tokens] |
+| [Cache] | [e.g., computed values, session data] | [e.g., PII, source-of-truth records] |
+
+## PII Boundaries
+
+- Which fields contain PII (enumerate every one)
+- Where PII is stored vs where it is NOT stored
+- How PII is isolated from AI/analytics pipelines
+- PII access logging requirements
+
+## GDPR/Compliance Data Lifecycle
+
+| Data Category | Retention Period | Deletion Trigger | Deletion Responsibility | Verification |
+|--------------|-----------------|-----------------|------------------------|-------------|
+| [e.g., Account data] | [e.g., Account lifetime + 30 days] | [e.g., Account deletion request] | [e.g., API server → database cascade] | [How deletion is verified] |
+| [e.g., Usage analytics] | [e.g., 90 days] | [e.g., TTL expiry] | [e.g., Database auto-purge] | [How deletion is verified] |
+
+## Tenancy Model
+
+[Single-tenant / Multi-tenant / Hybrid]
+- Isolation mechanism: [e.g., row-level security, schema-per-tenant, database-per-tenant]
+- Data co-mingling rules: [What data is shared vs isolated]
+- Cross-tenant query prevention: [How enforced]
+
+## Sync Protocol (multi-surface only)
+
+- What data syncs between surfaces
+- Sync frequency and mechanism
+- Conflict resolution strategy
+- Network partition behavior
+
+## Summary Table
+
+| Layer | Stores | Does NOT Store |
+|-------|--------|---------------|
+| [Layer 1] | [List] | [List] |
+| [Layer 2] | [List] | [List] |
+```
+
+This document is consumed by `/write-be-spec` and `/write-architecture-spec` to ensure every spec places data consistently.