init fab

.envrc

@@ -0,0 +1,3 @@
+export IDEAS_FILE=fab/backlog.md
+
+export WORKTREE_INIT_SCRIPT="fab sync"

.gitignore

@@ -129,4 +129,17 @@ dist
 .yarn/build-state.yml
 .yarn/install-state.gz
 .pnp.*
-.idea/
+.idea/
+.fab-*
+
+/.agents
+
+/.claude
+
+/.cursor
+
+/.opencode
+
+/.codex
+
+/.gemini

docs/memory/index.md

@@ -0,0 +1,7 @@
+# Memory Index
+
+<!-- This index is maintained by /fab-continue (hydrate) when changes are completed. -->
+<!-- Each domain gets a row linking to its memory files. -->
+
+| Domain | Description | Memory Files |
+|--------|-------------|------|

docs/specs/index.md

@@ -0,0 +1,15 @@
+# Specifications Index
+
+> **Specs are pre-implementation artifacts** — what you *planned*. They capture conceptual design
+> intent, high-level decisions, and the "why" behind features. Specs are human-curated,
+> flat in structure, and deliberately size-controlled for quick reading.
+>
+> Contrast with [`docs/memory/index.md`](../memory/index.md): memory files are *post-implementation* —
+> what actually happened. Memory files are the authoritative source of truth for system behavior,
+> maintained by `/fab-continue` (hydrate).
+>
+> **Ownership**: Specs are written and maintained by humans. No automated tooling creates or
+> enforces structure here — organize files however makes sense for your project.
+
+| Spec | Description |
+|------|-------------|

fab/.kit-migration-version

@@ -0,0 +1 @@
+0.1.0

fab/project/code-quality.md

@@ -0,0 +1,28 @@
+# Code Quality
+
+<!-- Optional coding standards consumed during apply and review.
+     Projects opt in by creating this file. All sections are independently optional.
+     Delete or leave empty any section that doesn't apply to your project. -->
+
+## Principles
+
+<!-- Positive coding standards to follow during implementation. -->
+
+- Readability and maintainability over cleverness
+- Follow existing project patterns unless there's compelling reason to deviate
+- Prefer composition over inheritance
+
+## Anti-Patterns
+
+<!-- Patterns to avoid. Flagged during review with file:line references on violation. -->
+
+- God functions (>50 lines without clear reason)
+- Duplicating existing utilities instead of reusing them
+- Magic strings or numbers without named constants
+
+## Test Strategy
+
+<!-- How tests relate to implementation.
+     Values: test-alongside (default) | test-after | tdd -->
+
+test-alongside

fab/project/code-review.md

@@ -0,0 +1,52 @@
+# Code Review
+
+<!-- Optional review policy consumed by the validation sub-agent during review.
+     Projects opt in by creating this file. All sections are independently optional.
+     Delete or leave empty any section that doesn't apply to your project.
+
+     This file guides the REVIEWING agent (critic). For the WRITING agent (author),
+     see code-quality.md. Different cognitive modes, different concerns. -->
+
+## Severity Definitions
+
+<!-- How findings are prioritized. The review sub-agent classifies each finding
+     into one of these tiers. Override the defaults below to match your project's
+     quality bar. -->
+
+- **Must-fix**: Spec mismatches, failing tests, checklist violations — always addressed during rework
+- **Should-fix**: Code quality issues, pattern inconsistencies — addressed when clear and low-effort
+- **Nice-to-have**: Style suggestions, minor improvements — may be skipped
+
+## Review Scope
+
+<!-- What the review sub-agent inspects. Adjust to exclude generated code,
+     vendor directories, or other paths that shouldn't be reviewed. -->
+
+- Changed files only (files touched during apply)
+- Skip generated code and vendor directories
+- Skip binary files and assets
+
+## False Positive Policy
+
+<!-- How to suppress or override findings the reviewer flags incorrectly.
+     Use inline comments in source code to mark intentional deviations. -->
+
+- Inline `<!-- review-ignore: {reason} -->` in markdown files
+- Inline `// review-ignore: {reason}` or `# review-ignore: {reason}` in code files
+- Suppressed findings are noted in the review report but not counted as failures
+
+## Rework Budget
+
+<!-- Max auto-rework cycles before escalating to the user.
+     Applies to /fab-fff and /fab-ff auto-rework loops. -->
+
+- Max cycles: 3
+- After 2 consecutive "fix code" attempts on the same issue, escalate to "revise tasks" or "revise spec"
+
+## Project-Specific Review Rules
+
+<!-- Add project-specific review rules here. Examples:
+     - All public APIs need integration tests
+     - No new dependencies without justification in the spec
+     - Database migrations must be reversible
+     - All user-facing strings must be internationalized -->

fab/project/config.yaml

@@ -0,0 +1 @@
+fab_version: 1.3.1

fab/project/constitution.md

@@ -0,0 +1,18 @@
+# {Project Name} Constitution
+
+## Core Principles
+
+### I. {Principle Name}
+{Description using MUST/SHALL/SHOULD keywords. Include rationale.}
+
+<!-- Generate 3-7 principles based on the project's actual patterns, tech stack, and constraints -->
+
+## Additional Constraints
+<!-- Project-specific: security, performance, testing, etc. -->
+
+### Test Integrity
+Tests MUST conform to the implementation spec — never the other way around. When tests fail, the fix SHALL either (a) update the tests to match the spec, or (b) update the implementation to match the spec. Modifying implementation code solely to accommodate test fixtures or test infrastructure is prohibited. Specs are the source of truth; tests verify conformance to specs.
+
+## Governance
+
+**Version**: 1.0.0 | **Ratified**: {DATE} | **Last Amended**: {DATE}

fab/project/context.md

@@ -0,0 +1,18 @@
+# Project Context
+
+<!-- Free-form project context: tech stack, conventions, architecture.
+     This is the primary way skills understand your codebase without reading every file.
+     Write naturally in markdown — no YAML constraints.
+
+     Tips:
+       - Be specific about languages, frameworks, and patterns
+       - For monorepos, use labeled sections so skills scope to the relevant part:
+
+         ## packages/frontend
+         React, TypeScript, Next.js, Tailwind CSS
+
+         ## packages/backend
+         Python, FastAPI, SQLAlchemy, PostgreSQL
+-->
+
+{TECH_STACK_AND_CONVENTIONS}

fab/sync/README.md

@@ -0,0 +1,9 @@
+# Project-Specific Sync Scripts
+
+Scripts in this directory run during `fab sync` after the kit-level sync operations.
+
+## Naming Convention
+
+- Use numbered `*.sh` files: `1-first.sh`, `2-second.sh`, etc.
+- Scripts execute in sorted order.
+- Each script should be idempotent (safe to re-run).