gspec 1.17.1 → 1.18.0

package/dist/opencode/gspec-implement/SKILL.md

@@ -26,7 +26,7 @@ Before writing any code, read all available gspec documents in this order:
 1. `gspec/profile.md` — Understand what the product is and who it's for
 2. `gspec/features/*.md` — Understand individual feature requirements and dependencies
    > **Note:** Feature PRDs are designed to be portable and project-agnostic. They describe *what* behavior is needed without referencing specific personas, design systems, or technology stacks. During implementation, you resolve project-specific context by combining features with the profile, style, stack, and practices documents read in this phase.
-3. `gspec/features/*.tasks.md` — For any feature in scope, also read its tasks file if one exists. Tasks files are produced by `gspec-tasks` and contain an ordered, dependency-aware breakdown of the PRD's capabilities into concrete implementation tasks with `[P]` parallel markers and explicit `deps:` lines. **When a tasks file exists, it is the authoritative build order for that feature.** When it doesn't exist, fall back to the PRD's checkbox capabilities directly.
+3. `gspec/features/*.plan.md` — For any feature in scope, also read its plan file if one exists. Plan files are produced by `gspec-plan` and contain an ordered, dependency-aware breakdown of the PRD's capabilities into concrete implementation tasks with `[P]` parallel markers and explicit `deps:` lines. **When a plan file exists, it is the authoritative, already-approved build order for that feature** — its Phase 4 plan-mode approval in `gspec-plan` is what licenses this skill to skip its own plan-mode step (see Phase 2). When it doesn't exist, fall back to the PRD's checkbox capabilities directly.
 4. `gspec/stack.md` — Understand the technology choices
 5. `gspec/style.md` **or** `gspec/style.html` — Understand the visual design language. The style guide may be in either format; read whichever exists (or both, if both are present — the HTML file contains the renderable token definitions and visual examples, the Markdown file contains prose rationale)
 6. `gspec/design/**` — If this folder exists, read every mockup in it. Supported formats include HTML pages, SVG files, and image files (PNG, JPG, WEBP). These are visual mockups (typically produced by external design tools like Figma, v0, Framer AI, etc.) that show layout, composition, and visual intent for specific screens or flows. **Treat them as authoritative visual guidance** — when building UI for a feature, look for relevant mockups in `gspec/design/` and match their layout, spacing, and hierarchy within the constraints of the style guide
@@ -47,7 +47,7 @@ This command is designed to be **run multiple times** as features are added or e
 - **`- [ ]`** (unchecked) = capability not yet implemented — include in this run's scope
 - **No checkbox prefix** = treat as not yet implemented (backwards compatible with older PRDs)
 
-**When a feature has a tasks file** (`gspec/features/<feature>.tasks.md`), also assess task-level state:
+**When a feature has a plan file** (`gspec/features/<feature>.plan.md`), also assess task-level state:
 
 - A task with `- [x]` is complete; skip unless user requests re-implementation
 - A task with `- [ ]` is pending and goes into this run's scope
@@ -55,24 +55,38 @@ This command is designed to be **run multiple times** as features are added or e
 
 For each feature PRD, build an implementation status summary:
 
-> **Feature: User Authentication** — 4/7 capabilities implemented (all P0 done, 3 P1/P2 remaining); tasks file shows 8/14 tasks done
-> **Feature: Dashboard** — 0/5 capabilities implemented (new feature, no tasks file)
+> **Feature: User Authentication** — 4/7 capabilities implemented (all P0 done, 3 P1/P2 remaining); plan file shows 8/14 tasks done
+> **Feature: Dashboard** — 0/5 capabilities implemented (new feature, no plan file)
 
 Present this summary to the user so they understand the starting point. If **all capabilities across all features are already checked**, inform the user and ask what they'd like to do — they may want to add new features, re-implement something, or they may be done.
 
 ### Phase 2: Plan — Define the Build Order
 
+#### Skip plan mode when every in-scope feature has a plan file
+
+Before entering plan mode, check whether **every** in-scope feature has a `gspec/features/<feature>.plan.md` file. If so, **do not enter plan mode** — the plan files are the build order, and they were already approved by the user during `gspec-plan`'s Phase 4. Re-asking for approval here is redundant and slows the user down.
+
+When the skip condition is met:
+
+1. Build the phase breakdown directly from the plan files — group unchecked tasks into phases by their `deps:` ordering, treating `[P]`-marked tasks as parallel-safe siblings within a phase. The phase boundaries should fall at natural dependency frontiers.
+2. **Verify plan-file ↔ PRD coverage before proceeding.** For each in-scope feature, confirm that every unchecked PRD capability has at least one covering task in the plan file. If you find an unchecked capability with no covering task (the PRD was extended after the plan file was written), flag it to the user and ask whether to (a) extend the plan via `/gspec-plan`, (b) implement that capability under an ad-hoc plan-mode pass for just those capabilities, or (c) defer it. Do not silently skip uncovered capabilities.
+3. Present a one-screen build summary — phases, task IDs per phase, parallel groups, and total task count — and start Phase 3 immediately. The summary is informational, not a plan-mode gate; the user can interrupt if they want to redirect, but no explicit approval is required.
+
+When the skip condition is **not** met (at least one in-scope feature has no plan file), run the full plan-mode workflow below for the entire scope. Features that do have plan files still drive their own ordering from their plan files inside the larger plan, but the user reviews the consolidated plan as a whole.
+
+#### Full plan mode (when one or more in-scope features lack a plan file)
+
 **Enter plan mode** and create a concrete, phased implementation plan.
 
-1. **Survey the full scope** — Review all feature PRDs and identify every unchecked capability that is in scope for this run. For features that have a tasks file, the unchecked tasks (not just capabilities) are the actual unit of work.
+1. **Survey the full scope** — Review all feature PRDs and identify every unchecked capability that is in scope for this run. For features that have a plan file, the unchecked tasks (not just capabilities) are the actual unit of work.
 2. **Organize into implementation phases** — Group related work into logical phases that can be built and verified independently. Each phase should:
    - Have a clear name and objective (e.g., "Phase 1: Core Data Models & API", "Phase 2: Authentication Flow")
-   - List the specific capabilities (with feature PRD references) it will implement, **and the specific tasks (by ID, e.g. T1, T2, T7) when a tasks file exists**
+   - List the specific capabilities (with feature PRD references) it will implement, **and the specific tasks (by ID, e.g. T1, T2, T7) when a plan file exists**
    - Identify files to create or modify
    - Note dependencies on prior phases
    - Include an estimated scope (small/medium/large)
-   - **When tasks files exist for in-scope features**, respect the `deps:` ordering they declare (no task may be scheduled before its declared deps), and note `[P]`-marked tasks as parallel-safe within a phase so the phase can fan-out work where appropriate
-3. **Account for every unchecked unit of work** — The plan must explicitly place every unchecked capability (or every unchecked task, when a tasks file exists) from in-scope feature PRDs into a phase **or** list it under a "Proposed to Defer" section with a reason. Nothing unchecked may be silently omitted from the plan. The user reviews and approves what gets deferred at plan approval time.
+   - **When plan files exist for in-scope features**, respect the `deps:` ordering they declare (no task may be scheduled before its declared deps), and note `[P]`-marked tasks as parallel-safe within a phase so the phase can fan-out work where appropriate
+3. **Account for every unchecked unit of work** — The plan must explicitly place every unchecked capability (or every unchecked task, when a plan file exists) from in-scope feature PRDs into a phase **or** list it under a "Proposed to Defer" section with a reason. Nothing unchecked may be silently omitted from the plan. The user reviews and approves what gets deferred at plan approval time.
 4. **Define test expectations per phase** — For each phase, specify what tests will be run to verify correctness before moving on (unit tests, integration tests, build verification, etc.)
 5. **Present the plan** — Show the user the full phased plan with clear phase boundaries and ask for approval
 
@@ -122,8 +136,8 @@ Present a brief scaffold summary to the user before proceeding to feature implem
    d. **Match the mockups** — For UI work, if `gspec/design/` contains mockups relevant to the screen or flow you are building, match their layout, spacing, and visual hierarchy. Resolve any conflict between a mockup and the style guide in favor of the style guide's tokens and semantics, then adjust the layout to remain faithful to the mockup's intent. If a mockup shows a visual pattern that the style guide doesn't cover, pause and ask the user whether to extend the style guide or deviate from the mockup.
    e. **Satisfy the requirements** — Trace each piece of code back to a functional requirement in the feature PRD (if available) or to the user's stated goals and the approved implementation plan
 3. **Mark progress as you go** — Update checkboxes incrementally, never in a batch at the end. This ensures that if the session is interrupted, progress is not lost.
-   - **Tasks (when a tasks file exists)**: as soon as a task is complete and verified, flip its checkbox in `gspec/features/<feature>.tasks.md` from `- [ ]` to `- [x]`.
-   - **Capabilities**: flip a PRD capability checkbox from `- [ ]` to `- [x]` only after every task whose `covers:` references it is checked. If no tasks file exists for that feature, flip the capability checkbox immediately on completion (the original behavior). If a capability line did not have a checkbox prefix, add one as `- [x]`.
+   - **Tasks (when a plan file exists)**: as soon as a task is complete and verified, flip its checkbox in `gspec/features/<feature>.plan.md` from `- [ ]` to `- [x]`.
+   - **Capabilities**: flip a PRD capability checkbox from `- [ ]` to `- [x]` only after every task whose `covers:` references it is checked. If no plan file exists for that feature, flip the capability checkbox immediately on completion (the original behavior). If a capability line did not have a checkbox prefix, add one as `- [x]`.
    - When updating gspec files, preserve existing `spec-version` YAML frontmatter. If a file lacks frontmatter, add `---\nspec-version: v1\n---` at the top.
 4. **Run tests** — Execute the tests defined for this phase (and any existing tests to catch regressions). Fix any failures before proceeding.
 6. **Surface new gaps** — If implementation reveals new ambiguities, pause and consult the user rather than making silent assumptions
@@ -145,7 +159,7 @@ After implementation:
 2. **Review against acceptance criteria** — For each capability in the feature PRDs, check that every acceptance criterion listed under it is satisfied. These sub-listed conditions are the definition of "done" for each capability. If any criterion is not met, the capability should not be marked `[x]`.
 3. **Check the Definition of Done** from `gspec/practices.md`
 4. **Verify no unapproved deferrals** — Compare the final implementation against the approved plan. If any capability that was assigned to a phase was not implemented, **do not silently leave it unchecked**. Flag it to the user, explain why it wasn't completed, and get explicit approval before marking it as deferred. Only capabilities the user approved for deferral during planning (or explicitly approves now) may remain unchecked.
-5. **Verify checkbox accuracy** — Confirm that every capability marked `[x]` in the feature PRDs is genuinely implemented and working. Confirm that capabilities left as `[ ]` were approved for deferral by the user. **For features with tasks files**, also confirm task↔capability consistency: every checked capability has all its covering tasks checked, and every unchecked capability has at least one unchecked covering task. Present a final status summary:
+5. **Verify checkbox accuracy** — Confirm that every capability marked `[x]` in the feature PRDs is genuinely implemented and working. Confirm that capabilities left as `[ ]` were approved for deferral by the user. **For features with plan files**, also confirm task↔capability consistency: every checked capability has all its covering tasks checked, and every unchecked capability has at least one unchecked covering task. Present a final status summary:
 
 > **Implementation Summary:**
 > - Feature X: 7/7 capabilities implemented (complete)
@@ -200,7 +214,7 @@ The user's prompt takes priority for scoping. Use it to determine focus, and ref
 
 ## Output Rules
 
-- **Use plan mode** in Phase 2 to present the implementation plan. Wait for user approval before proceeding.
+- **Use plan mode** in Phase 2 to present the implementation plan, **unless every in-scope feature has a plan file** — in that case, skip plan mode and proceed directly to Phase 3 using the plan files as the authoritative build order. Wait for user approval whenever plan mode runs.
 - **Pause between implementation phases** — After completing each phase in Phase 3, run tests and wait for user confirmation before starting the next phase
 - Reference specific gspec documents and section numbers when discussing requirements
 - Create files following the project structure defined in `gspec/architecture.md` (or `gspec/stack.md` and `gspec/practices.md` if no architecture document exists)

package/dist/opencode/gspec-migrate/SKILL.md

@@ -17,6 +17,7 @@ Scan the `gspec/` directory for all spec files:
 - `gspec/*.md` (profile, stack, style, practices, architecture)
 - `gspec/style.html` (HTML design system, if present — the style guide may be in either Markdown or HTML)
 - `gspec/features/*.md` (individual feature PRDs)
+- `gspec/features/*.plan.md` (plan files; legacy `*.tasks.md` files are also scanned and renamed — see Migration Rules below)
 
 Do **not** migrate files under `gspec/design/` — those are external design mockups (HTML, SVG, PNG, JPG) that are dropped in manually and are not owned by gspec. Leave them untouched.
 
@@ -107,6 +108,12 @@ After migrating all files:
 - If capabilities lack acceptance criteria (current format requires them), add placeholder criteria: "Acceptance criteria to be defined"
 - Preserve priority levels (P0, P1, P2)
 
+**Rename legacy `*.tasks.md` plan files to `*.plan.md`.** Before gspec renamed the `tasks` skill to `plan`, plan files lived at `gspec/features/<feature>.tasks.md`. During migration:
+- For every `gspec/features/*.tasks.md` file, rename it to `gspec/features/<same-slug>.plan.md` (use `git mv` when the project is a git repo so history is preserved; otherwise plain move)
+- Inside the renamed file, update the top-of-file heading from `# Tasks: <Feature Name>` to `# Plan: <Feature Name>` and the section heading from `## Tasks` to `## Plan`. Leave everything else (frontmatter, task IDs, `[P]` markers, `deps:`, `covers:`, checkbox states) unchanged
+- Preserve task IDs verbatim — `T1`, `T2`, etc. remain stable; do not renumber
+- Confirm the rename plan with the user before applying, in the same approval flow as other migrations
+
 **Handle missing sections gracefully.** If the current format requires a section that has no content in the old file, add the section heading with "To be defined" or "Not applicable" as appropriate.
 
 **Frontmatter handling (Markdown files):**

package/dist/{codex/gspec-tasks → opencode/gspec-plan}/SKILL.md

@@ -1,13 +1,13 @@
 ---
-name: gspec-tasks
-description: Decompose a feature PRD in gspec/features/ into an ordered, dependency-aware task plan with parallel-execution markers, written to gspec/features/<feature>.tasks.md. TRIGGER when the user wants to plan execution order, break a feature into tasks, identify what can run in parallel, sequence implementation work, or produce a build plan from a PRD — e.g. "break this feature into tasks", "what order should I build this in", "plan the implementation order", "make a task list for X", "what can run in parallel", "decompose feature Y", "ordered task plan". Run this AFTER gspec-feature and BEFORE gspec-implement when a feature is large or has non-obvious ordering. Prefer this skill over ad-hoc task lists.
+name: gspec-plan
+description: Decompose a feature PRD in gspec/features/ into an ordered, dependency-aware plan with parallel-execution markers, written to gspec/features/<feature>.plan.md. The plan is what gspec-implement consumes as its build order — when a plan file exists, gspec-implement skips its own plan-mode step. TRIGGER when the user wants to plan execution order, break a feature into tasks, identify what can run in parallel, sequence implementation work, or produce a build plan from a PRD — e.g. "plan this feature", "what order should I build this in", "plan the implementation order", "break this feature into tasks", "what can run in parallel", "decompose feature Y", "ordered build plan". Run this AFTER gspec-feature and BEFORE gspec-implement when a feature is large or has non-obvious ordering. Prefer this skill over ad-hoc task lists.
 ---
 
 You are a Senior Engineering Lead at a high-performing software company.
 
-Your task is to take a **feature PRD** from `gspec/features/` and decompose it into an **ordered, dependency-aware task plan** with parallel-execution markers. The output is a separate sibling file at `gspec/features/<feature>.tasks.md` that `gspec-implement` consumes during its planning phase.
+Your task is to take a **feature PRD** from `gspec/features/` and decompose it into an **ordered, dependency-aware plan** with parallel-execution markers. The output is a separate sibling file at `gspec/features/<feature>.plan.md` that `gspec-implement` consumes as its build order.
 
-The PRD answers *what* and *why*. The tasks file answers *how* and *in what order*.
+The PRD answers *what* and *why*. The plan file answers *how* and *in what order*.
 
 ## When to Run This Skill
 
@@ -24,8 +24,8 @@ Skip this skill for trivial features — `gspec-implement`'s checkbox-driven pla
 ## Inputs
 
 - **Required**: a feature PRD at `gspec/features/<feature>.md` (the user names the feature; if ambiguous, ask)
-- **Supporting context** (read but don't quote): `gspec/architecture.md`, `gspec/stack.md`. Use these only to inform task granularity and ordering — never to embed project-specific technology choices into the tasks file
-- **Existing tasks file** (if any) at `gspec/features/<feature>.tasks.md` — if present and non-empty, treat it as authoritative state and refuse to overwrite without explicit user confirmation
+- **Supporting context** (read but don't quote): `gspec/architecture.md`, `gspec/stack.md`. Use these only to inform task granularity and ordering — never to embed project-specific technology choices into the plan file
+- **Existing plan file** (if any) at `gspec/features/<feature>.plan.md` — if present and non-empty, treat it as authoritative state and refuse to overwrite without explicit user confirmation
 
 ---
 
@@ -35,7 +35,7 @@ Skip this skill for trivial features — `gspec-implement`'s checkbox-driven pla
 
 1. Read the target feature PRD in full. Extract every capability and its acceptance criteria.
 2. Read `gspec/architecture.md` and `gspec/stack.md` for ordering signals (e.g., schema must exist before API; API before UI).
-3. If a tasks file already exists for this feature, read it. Decide whether the user wants to (a) regenerate from scratch, (b) add tasks for newly added capabilities only, or (c) abort. Ask before proceeding.
+3. If a plan file already exists for this feature, read it. Decide whether the user wants to (a) regenerate from scratch, (b) add tasks for newly added capabilities only, or (c) abort. Ask before proceeding.
 
 ### Phase 2: Decompose
 
@@ -60,26 +60,28 @@ For each unchecked PRD capability:
 
 ### Phase 4: Plan-Mode Confirmation
 
-Enter plan mode and present the proposed tasks file content to the user. Show:
+Enter plan mode and present the proposed plan file content to the user. Show:
 
 - Total task count and how many `[P]`-marked
 - The full proposed file body
 - Any capabilities you could not decompose (explain why)
-- Any cross-feature dependencies you noticed (the user may want to address them in another feature's tasks file)
+- Any cross-feature dependencies you noticed (the user may want to address them in another feature's plan file)
 
 Wait for approval. The user may edit individual tasks, change ordering, drop or add `[P]` markers, or split/merge tasks.
 
+The user's approval here is what lets `gspec-implement` skip its own plan-mode step when it later consumes this file. Be deliberate — the plan you write here is the build order.
+
 ### Phase 5: Write
 
-After approval, write `gspec/features/<feature>.tasks.md`. Never overwrite a non-empty existing file without explicit user confirmation in Phase 1.
+After approval, write `gspec/features/<feature>.plan.md`. Never overwrite a non-empty existing file without explicit user confirmation in Phase 1.
 
-When writing, preserve any existing `spec-version` frontmatter from the prior tasks file. New files use `spec-version: v1`.
+When writing, preserve any existing `spec-version` frontmatter from the prior plan file. New files use `spec-version: v1`.
 
 ---
 
 ## Output Format
 
-The tasks file has YAML frontmatter and a single `## Tasks` section.
+The plan file has YAML frontmatter and a single `## Plan` section.
 
 ```markdown
 ---
@@ -87,9 +89,9 @@ spec-version: v1
 feature: <feature-slug>
 ---
 
-# Tasks: <Feature Name>
+# Plan: <Feature Name>
 
-## Tasks
+## Plan
 
 - [ ] **T1** [P] **P0** scaffold the Astro page route at `src/pages/index.astro`
   - deps: —
@@ -123,19 +125,19 @@ feature: <feature-slug>
 
 ## Relationship to PRD Checkboxes
 
-The tasks file and the PRD use **separate checkboxes**:
+The plan file and the PRD use **separate checkboxes**:
 
-- **Task checkboxes** (`- [ ]` / `- [x]` in the tasks file) track *execution state* — flip when the task is done.
+- **Task checkboxes** (`- [ ]` / `- [x]` in the plan file) track *execution state* — flip when the task is done.
 - **Capability checkboxes** (`- [ ]` / `- [x]` in the PRD) track *delivery state* — only flip when **every** task whose `covers:` references that capability is complete.
 
-`gspec-implement` is responsible for keeping both in sync. This skill only writes the initial unchecked tasks file.
+`gspec-implement` is responsible for keeping both in sync. This skill only writes the initial unchecked plan file.
 
 ---
 
 ## Output Rules
 
-- **Use plan mode** in Phase 4. Never write the tasks file before the user approves.
-- One tasks file per feature. Co-located with the PRD as `gspec/features/<feature>.tasks.md`.
+- **Use plan mode** in Phase 4. Never write the plan file before the user approves.
+- One plan file per feature. Co-located with the PRD as `gspec/features/<feature>.plan.md`.
 - Begin each file with the YAML frontmatter shown above.
 - Preserve existing frontmatter and existing task IDs when regenerating — append new tasks rather than renumbering.
 - If you discover the PRD itself is ambiguous (a capability has no clear acceptance criteria), pause and recommend the user run `gspec-feature` to refine the PRD before continuing. Do not invent acceptance criteria.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "gspec",
-    "version": "1.17.1",
+    "version": "1.18.0",
     "description": "Install gspec specification commands for Claude Code, Cursor, and other AI tools",
     "main": "bin/gspec.js",
     "type": "module",

package/templates/spec-sync.md

@@ -13,7 +13,7 @@ Use this mapping whenever the user's intent matches:
 - **Building, implementing, coding, scaffolding, shipping, or "making it real"** — invoke `gspec-implement`. This is the most commonly-missed skill. If the user asks you to write code for anything the specs describe (or a new capability that should be specced), route through `gspec-implement` rather than editing files directly. Generic prompts like "build it", "go", "keep going", "continue", or "do the next phase" should also invoke it when recent conversation has been about specs or planning.
 - **Defining the product, users, or vision** — invoke `gspec-profile`.
 - **Planning or writing a new feature / PRD** — invoke `gspec-feature`.
-- **Producing an ordered task plan from a feature PRD (with explicit dependencies and parallel-execution markers)** — invoke `gspec-tasks`. Run before `gspec-implement` for non-trivial features.
+- **Producing an ordered plan from a feature PRD (with explicit dependencies and parallel-execution markers)** — invoke `gspec-plan`. Run before `gspec-implement` for non-trivial features; when a plan file exists, `gspec-implement` skips its own plan-mode step.
 - **Choosing or revising the tech stack** — invoke `gspec-stack`.
 - **Defining visual design, tokens, or theme** — invoke `gspec-style`.
 - **Setting coding standards, testing, or workflow conventions** — invoke `gspec-practices`.
@@ -25,13 +25,17 @@ Use this mapping whenever the user's intent matches:
 
 If the user explicitly asks you to skip the skill and just do the work, honor that — but by default, prefer the skill.
 
+### Asking the user multiple questions
+
+When a skill needs feedback on more than one question, first preview all of them as a numbered list so the user knows the full scope, then ask them **one at a time** in the conversation. Never present multiple questions as a single numbered list expecting one combined reply — that forces the user to retype each question number alongside their answer. One question per turn keeps replies short and natural.
+
 ### When you make code changes, follow these rules:
 
 1. **Read the specs first** — Before making non-trivial changes, read the relevant gspec documents to understand existing decisions and constraints. At minimum, scan `gspec/profile.md` and any feature PRDs in `gspec/features/` related to your work.
 
 2. **Spec before you build** — If the user asks for a feature or capability that isn't covered by an existing feature PRD in `gspec/features/`, run the `gspec-feature` command to create a new feature PRD before implementing it. Every feature should be specified before it's built — don't skip straight to code.
 
-3. **Update feature checkboxes** — When you implement a capability defined in a feature PRD (`gspec/features/*.md`), change its checkbox from `- [ ]` to `- [x]`. **If a tasks file exists** at `gspec/features/<feature>.tasks.md`, also flip the checkbox of each completed task in that file. Only flip the PRD capability checkbox once every task whose `covers:` references it is checked.
+3. **Update feature checkboxes** — When you implement a capability defined in a feature PRD (`gspec/features/*.md`), change its checkbox from `- [ ]` to `- [x]`. **If a plan file exists** at `gspec/features/<feature>.plan.md`, also flip the checkbox of each completed task in that file. Only flip the PRD capability checkbox once every task whose `covers:` references it is checked.
 
 4. **Update specs that your changes contradict** — If your code change makes a spec statement incorrect (e.g., you changed the data model, switched a dependency, altered a UI pattern, or added a new API endpoint), update the spec to reflect reality. Common candidates:
    - `gspec/architecture.md` — project structure, data model, API routes, component hierarchy