Update project templates for Trust 1 and SpecSync 5

.attest.json

@@ -0,0 +1,4 @@
+{
+  "requireAttestation": true,
+  "requireTestsPassed": true
+}

.augur.toml

@@ -0,0 +1,3 @@
+[thresholds]
+review = 35
+block = 65

.claude/commands/specsync/create-change.md

@@ -0,0 +1,10 @@
+---
+description: Create and guide a verified spec-sync SDD change through its deterministic interview
+argument-hint: <change-description>
+---
+
+1. Run `specsync change new "$ARGUMENTS" --json`.
+2. Read the returned `questions` array and interview the user one question at a time.
+3. Record each answer with `specsync change answer <id> <question-id> <answer> --json`.
+4. Continue until the question list is empty, then show the selected artifacts and next action.
+5. Do not approve, implement, verify, accept, or archive until the corresponding human gate or work stage is reached.

.claude/commands/specsync/create-spec.md

@@ -0,0 +1,40 @@
+---
+description: Scaffold a new spec-sync module spec from a module name or a natural-language feature description (full scaffold by default, or minimal with --minimal)
+argument-hint: <module-name-or-description> [--minimal]
+---
+
+Create a new spec-sync module spec.
+
+Arguments: `$ARGUMENTS`
+
+1. Parse the arguments above. If they contain `--minimal` (in any position),
+   remove that flag and remember that minimal mode was requested. Preserve all
+   other text exactly; do not choose a module name yet.
+2. Classify the complete remaining text. It will be one of:
+   - **A bare module name** — a short identifier like `auth-service` or
+     `billing`. Use it as-is.
+   - **A free-text feature description** — a sentence or phrase describing
+     what to build, e.g. `"I want a feature that lets users export their
+     data as CSV"`. In this case, invent a short, kebab-case module name that
+     captures the idea (e.g. `csv-export`). If the right name is ambiguous,
+     ask the user to confirm or rename it before continuing. Keep the full
+     description at hand — you'll use it in step 5.
+3. If minimal mode was requested, run:
+   ```
+   specsync new <module-name>
+   ```
+   This creates a minimal spec only (no companion files).
+4. Otherwise (default), run:
+   ```
+   specsync scaffold <module-name>
+   ```
+   This creates the spec, companion files (`tasks.md`, `requirements.md`,
+   `context.md`, `testing.md`, and `design.md` if `companions.design` is
+   enabled), a registry entry, and auto-detects related source files.
+5. Open the newly created `specs/<module-name>/<module-name>.spec.md` and fill
+   in the `Purpose`, `Requirements`, and `Public API` sections. If a free-text
+   description was given in step 2, use it directly to draft these sections —
+   ask clarifying questions if it's underspecified, but do not leave the
+   sections as unfilled placeholder text. Do the same for `requirements.md`
+   (acceptance criteria) and `tasks.md` (initial task breakdown), if present.
+6. Run `specsync check` to confirm the new spec passes validation.

.claude/skills/spec-sync/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: spec-sync
+description: Keep markdown module specs in specs/<module>/ synchronized with source code using spec-sync. Use this whenever creating, editing, or reviewing code in a module that has (or should have) a spec, or whenever the user mentions specs, spec-sync, companion files (tasks.md/requirements.md/context.md/testing.md/design.md), or asks to add/update a module's documentation.
+---
+
+# Spec-Sync Workflow
+
+This project uses [spec-sync](https://github.com/CorvidLabs/spec-sync) for bidirectional spec-to-code validation. Specs live in `specs/<module>/<module>.spec.md`.
+
+## Companion files
+
+## Verified SDD change lifecycle (5.0)
+
+For every meaningful source, test, public documentation, schema, or configuration change:
+
+1. Run `specsync change new "<intent>" --json` and conduct the returned interview with the user.
+2. Use `specsync change answer <id> <question-id> <answer> --json` until no questions remain.
+3. Complete the adaptively selected artifacts and semantic deltas. Requirements use stable
+   `REQ-<module>-<number>` IDs, a normative SHALL statement, and acceptance criteria.
+4. Ask the user for the definition approval, then run `specsync change approve <id>`.
+5. Run `specsync change start <id>` before editing implementation code.
+6. Keep tasks and artifacts current, then run `specsync change verify <id>`.
+7. Present verification evidence and ask for closing approval. Only after explicit approval,
+   run `specsync change accept <id>`; archive separately with `specsync change archive <id>`.
+
+Never invent or self-grant either human approval. If an approved definition changes, its digest
+becomes stale and must be approved again. `specsync check` validates canonical specs plus approved
+active deltas, requirement-to-test evidence, change coverage, and CI gates.
+
+Each canonical spec may have policy-selected companion files. Read and update the ones present; do not create empty companions only for ceremony:
+
+- **`tasks.md`** — Work items for this module. Check off tasks (`- [x]`) as you complete them. Add new tasks if you discover work needed.
+- **`requirements.md`** — Acceptance criteria and user stories. These are permanent invariants, not tasks — do not check them off. Update if requirements change.
+- **`context.md`** — Architectural decisions, key files, and current status. Update when you make design decisions or change what's in progress.
+- **`testing.md`** — Test strategy: automated test locations, manual QA checklists, and edge cases/boundary conditions.
+- **`design.md`** *(opt-in)* — Layout, component hierarchy, design tokens, and asset references. Present when `companions.design` is enabled in config.
+
+## Before modifying any module
+
+1. Read the relevant spec in `specs/<module>/<module>.spec.md`
+2. Read whichever companion files are present (`requirements.md`, `tasks.md`, `context.md`, `testing.md`, `design.md`, or project-defined files)
+3. After changes, run `specsync check` to verify specs still pass
+
+## After completing work
+
+1. Mark completed items in `tasks.md` — check off finished tasks, add new ones discovered
+2. Update `context.md` — record decisions made, update current status
+3. If requirements changed, update `requirements.md` acceptance criteria
+4. If test coverage changed, update `testing.md` with new test files or edge cases
+5. If UI/layout changed, update `design.md` with revised layout, components, or tokens
+
+## Before creating a PR
+
+Run `specsync check --strict` — all specs must pass with zero warnings.
+
+## When adding new modules
+
+Run `specsync scaffold <module-name>` to create a spec, companion files, a registry
+entry, and auto-detected source files — or `specsync new <module-name>` for a
+minimal spec-only draft. Complete the spec before writing code. The
+`/specsync:create-spec` command (or tool-equivalent) runs this for you, and
+accepts either a bare module name or a natural-language feature description
+(e.g. `/specsync:create-spec "I want a feature that lets users export their
+data as CSV"`) — pass a description and it will pick a module name and use
+the description to draft the spec's Purpose and Requirements.
+
+## Key commands
+
+- `specsync check` — validate all specs against source code
+- `specsync check --json` — machine-readable validation output
+- `specsync coverage` — show which modules lack specs
+- `specsync score` — quality score for each spec (0-100)
+- `specsync scaffold <name>` — full scaffold: spec + companions + registry entry + source detection
+- `specsync new <name>` — quick-create a minimal spec (add `--full` for companions)
+- `specsync resolve --remote` — verify cross-project dependencies

.codex/skills/spec-sync/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: spec-sync
+description: Keep markdown module specs in specs/<module>/ synchronized with source code using spec-sync. Use this whenever creating, editing, or reviewing code in a module that has (or should have) a spec, or whenever the user mentions specs, spec-sync, companion files (tasks.md/requirements.md/context.md/testing.md/design.md), or asks to add/update a module's documentation.
+---
+
+# Spec-Sync Workflow
+
+This project uses [spec-sync](https://github.com/CorvidLabs/spec-sync) for bidirectional spec-to-code validation. Specs live in `specs/<module>/<module>.spec.md`.
+
+## Companion files
+
+## Verified SDD change lifecycle (5.0)
+
+For every meaningful source, test, public documentation, schema, or configuration change:
+
+1. Run `specsync change new "<intent>" --json` and conduct the returned interview with the user.
+2. Use `specsync change answer <id> <question-id> <answer> --json` until no questions remain.
+3. Complete the adaptively selected artifacts and semantic deltas. Requirements use stable
+   `REQ-<module>-<number>` IDs, a normative SHALL statement, and acceptance criteria.
+4. Ask the user for the definition approval, then run `specsync change approve <id>`.
+5. Run `specsync change start <id>` before editing implementation code.
+6. Keep tasks and artifacts current, then run `specsync change verify <id>`.
+7. Present verification evidence and ask for closing approval. Only after explicit approval,
+   run `specsync change accept <id>`; archive separately with `specsync change archive <id>`.
+
+Never invent or self-grant either human approval. If an approved definition changes, its digest
+becomes stale and must be approved again. `specsync check` validates canonical specs plus approved
+active deltas, requirement-to-test evidence, change coverage, and CI gates.
+
+Each canonical spec may have policy-selected companion files. Read and update the ones present; do not create empty companions only for ceremony:
+
+- **`tasks.md`** — Work items for this module. Check off tasks (`- [x]`) as you complete them. Add new tasks if you discover work needed.
+- **`requirements.md`** — Acceptance criteria and user stories. These are permanent invariants, not tasks — do not check them off. Update if requirements change.
+- **`context.md`** — Architectural decisions, key files, and current status. Update when you make design decisions or change what's in progress.
+- **`testing.md`** — Test strategy: automated test locations, manual QA checklists, and edge cases/boundary conditions.
+- **`design.md`** *(opt-in)* — Layout, component hierarchy, design tokens, and asset references. Present when `companions.design` is enabled in config.
+
+## Before modifying any module
+
+1. Read the relevant spec in `specs/<module>/<module>.spec.md`
+2. Read whichever companion files are present (`requirements.md`, `tasks.md`, `context.md`, `testing.md`, `design.md`, or project-defined files)
+3. After changes, run `specsync check` to verify specs still pass
+
+## After completing work
+
+1. Mark completed items in `tasks.md` — check off finished tasks, add new ones discovered
+2. Update `context.md` — record decisions made, update current status
+3. If requirements changed, update `requirements.md` acceptance criteria
+4. If test coverage changed, update `testing.md` with new test files or edge cases
+5. If UI/layout changed, update `design.md` with revised layout, components, or tokens
+
+## Before creating a PR
+
+Run `specsync check --strict` — all specs must pass with zero warnings.
+
+## When adding new modules
+
+Run `specsync scaffold <module-name>` to create a spec, companion files, a registry
+entry, and auto-detected source files — or `specsync new <module-name>` for a
+minimal spec-only draft. Complete the spec before writing code. The
+`/specsync:create-spec` command (or tool-equivalent) runs this for you, and
+accepts either a bare module name or a natural-language feature description
+(e.g. `/specsync:create-spec "I want a feature that lets users export their
+data as CSV"`) — pass a description and it will pick a module name and use
+the description to draft the spec's Purpose and Requirements.
+
+## Key commands
+
+- `specsync check` — validate all specs against source code
+- `specsync check --json` — machine-readable validation output
+- `specsync coverage` — show which modules lack specs
+- `specsync score` — quality score for each spec (0-100)
+- `specsync scaffold <name>` — full scaffold: spec + companions + registry entry + source detection
+- `specsync new <name>` — quick-create a minimal spec (add `--full` for companions)
+- `specsync resolve --remote` — verify cross-project dependencies

.cursor/commands/specsync-create-change.md

@@ -0,0 +1,9 @@
+Create a verified spec-sync SDD change.
+
+Arguments: $ARGUMENTS
+
+1. Run `specsync change new "$ARGUMENTS" --json`.
+2. Read the returned `questions` array and interview the user one question at a time.
+3. Record each answer with `specsync change answer <id> <question-id> <answer> --json`.
+4. Continue until the question list is empty, then show the selected artifacts and next action.
+5. Do not approve, implement, verify, accept, or archive until the corresponding human gate or work stage is reached.

.cursor/commands/specsync-create-spec.md

@@ -0,0 +1,34 @@
+Create a new spec-sync module spec.
+
+Arguments: $ARGUMENTS
+
+1. Remove `--minimal` wherever it appears and remember that minimal mode was
+   requested. Preserve the complete remaining text; do not tokenize it yet.
+2. Classify the complete remaining text:
+   - **A bare module name** — a short identifier like `auth-service` or
+     `billing`, matching `^[A-Za-z0-9][A-Za-z0-9._-]*$`. Use it as-is.
+   - **A free-text feature description** — a sentence or phrase describing
+     what to build, e.g. `"I want a feature that lets users export their
+     data as CSV"`. In this case, invent a short, kebab-case module name that
+     captures the idea (e.g. `csv-export`). If the right name is ambiguous,
+     ask the user to confirm or rename it before continuing. Keep the full
+     description at hand — you'll use it in step 5.
+3. If minimal mode was requested, run:
+   ```
+   specsync new <module-name>
+   ```
+   This creates a minimal spec only (no companion files).
+4. Otherwise (default), run:
+   ```
+   specsync scaffold <module-name>
+   ```
+   This creates the spec, companion files (`tasks.md`, `requirements.md`,
+   `context.md`, `testing.md`, and `design.md` if `companions.design` is
+   enabled), a registry entry, and auto-detects related source files.
+5. Open the newly created `specs/<module-name>/<module-name>.spec.md` and fill
+   in the `Purpose`, `Requirements`, and `Public API` sections. If a free-text
+   description was given in step 2, use it directly to draft these sections —
+   ask clarifying questions if it's underspecified, but do not leave the
+   sections as unfilled placeholder text. Do the same for `requirements.md`
+   (acceptance criteria) and `tasks.md` (initial task breakdown), if present.
+6. Run `specsync check` to confirm the new spec passes validation.

.cursor/skills/spec-sync/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: spec-sync
+description: Keep markdown module specs in specs/<module>/ synchronized with source code using spec-sync. Use this whenever creating, editing, or reviewing code in a module that has (or should have) a spec, or whenever the user mentions specs, spec-sync, companion files (tasks.md/requirements.md/context.md/testing.md/design.md), or asks to add/update a module's documentation.
+---
+
+# Spec-Sync Workflow
+
+This project uses [spec-sync](https://github.com/CorvidLabs/spec-sync) for bidirectional spec-to-code validation. Specs live in `specs/<module>/<module>.spec.md`.
+
+## Companion files
+
+## Verified SDD change lifecycle (5.0)
+
+For every meaningful source, test, public documentation, schema, or configuration change:
+
+1. Run `specsync change new "<intent>" --json` and conduct the returned interview with the user.
+2. Use `specsync change answer <id> <question-id> <answer> --json` until no questions remain.
+3. Complete the adaptively selected artifacts and semantic deltas. Requirements use stable
+   `REQ-<module>-<number>` IDs, a normative SHALL statement, and acceptance criteria.
+4. Ask the user for the definition approval, then run `specsync change approve <id>`.
+5. Run `specsync change start <id>` before editing implementation code.
+6. Keep tasks and artifacts current, then run `specsync change verify <id>`.
+7. Present verification evidence and ask for closing approval. Only after explicit approval,
+   run `specsync change accept <id>`; archive separately with `specsync change archive <id>`.
+
+Never invent or self-grant either human approval. If an approved definition changes, its digest
+becomes stale and must be approved again. `specsync check` validates canonical specs plus approved
+active deltas, requirement-to-test evidence, change coverage, and CI gates.
+
+Each canonical spec may have policy-selected companion files. Read and update the ones present; do not create empty companions only for ceremony:
+
+- **`tasks.md`** — Work items for this module. Check off tasks (`- [x]`) as you complete them. Add new tasks if you discover work needed.
+- **`requirements.md`** — Acceptance criteria and user stories. These are permanent invariants, not tasks — do not check them off. Update if requirements change.
+- **`context.md`** — Architectural decisions, key files, and current status. Update when you make design decisions or change what's in progress.
+- **`testing.md`** — Test strategy: automated test locations, manual QA checklists, and edge cases/boundary conditions.
+- **`design.md`** *(opt-in)* — Layout, component hierarchy, design tokens, and asset references. Present when `companions.design` is enabled in config.
+
+## Before modifying any module
+
+1. Read the relevant spec in `specs/<module>/<module>.spec.md`
+2. Read whichever companion files are present (`requirements.md`, `tasks.md`, `context.md`, `testing.md`, `design.md`, or project-defined files)
+3. After changes, run `specsync check` to verify specs still pass
+
+## After completing work
+
+1. Mark completed items in `tasks.md` — check off finished tasks, add new ones discovered
+2. Update `context.md` — record decisions made, update current status
+3. If requirements changed, update `requirements.md` acceptance criteria
+4. If test coverage changed, update `testing.md` with new test files or edge cases
+5. If UI/layout changed, update `design.md` with revised layout, components, or tokens
+
+## Before creating a PR
+
+Run `specsync check --strict` — all specs must pass with zero warnings.
+
+## When adding new modules
+
+Run `specsync scaffold <module-name>` to create a spec, companion files, a registry
+entry, and auto-detected source files — or `specsync new <module-name>` for a
+minimal spec-only draft. Complete the spec before writing code. The
+`/specsync:create-spec` command (or tool-equivalent) runs this for you, and
+accepts either a bare module name or a natural-language feature description
+(e.g. `/specsync:create-spec "I want a feature that lets users export their
+data as CSV"`) — pass a description and it will pick a module name and use
+the description to draft the spec's Purpose and Requirements.
+
+## Key commands
+
+- `specsync check` — validate all specs against source code
+- `specsync check --json` — machine-readable validation output
+- `specsync coverage` — show which modules lack specs
+- `specsync score` — quality score for each spec (0-100)
+- `specsync scaffold <name>` — full scaffold: spec + companions + registry entry + source detection
+- `specsync new <name>` — quick-create a minimal spec (add `--full` for companions)
+- `specsync resolve --remote` — verify cross-project dependencies

.gemini/commands/specsync/create-change.toml

@@ -0,0 +1,11 @@
+description = "Create and guide a verified spec-sync SDD change through its deterministic interview"
+
+prompt = """
+Arguments: {{args}}
+
+1. Run `specsync change new "{{args}}" --json`.
+2. Read the returned `questions` array and interview the user one question at a time.
+3. Record each answer with `specsync change answer <id> <question-id> <answer> --json`.
+4. Continue until the question list is empty, then show the selected artifacts and next action.
+5. Do not approve, implement, verify, accept, or archive until the corresponding human gate or work stage is reached.
+"""