/trellis-update-spec

name: trellis-update-spec
description: "Captures executable contracts and coding conventions into .trellis/spec/ documents. Use when learning something valuable from debugging, implementing, or discussion that should be preserved for future sessions."

Update Code-Spec - Capture Executable Contracts

When you learn something valuable (from debugging, implementing, or discussion), use this to update the relevant code-spec documents.

**Timing**: After completing a task, fixing a bug, or discovering a new pattern

---

Code-Spec First Rule (CRITICAL)

In this project, "spec" for implementation work means **code-spec**:

• Executable contracts (not principle-only text)
• Concrete signatures, payload fields, env keys, and boundary behavior
• Testable validation/error behavior

If the change touches infra or cross-layer contracts, code-spec depth is mandatory.

Mandatory Triggers

Apply code-spec depth when the change includes any of:

• New/changed command or API signature
• Cross-layer request/response contract change
• Database schema/migration change
• Infra integration (storage, queue, cache, secrets, env wiring)

Mandatory Output (7 Sections)

For triggered tasks, include all sections below: 1. Scope / Trigger 2. Signatures (command/API/DB) 3. Contracts (request/response/env) 4. Validation & Error Matrix 5. Good/Base/Bad Cases 6. Tests Required (with assertion points) 7. Wrong vs Correct (at least one pair)

---

When to Update Code-Specs

| Trigger | Example | Target Spec | |---------|---------|-------------| | **Implemented a feature** | Added a new integration or module | Relevant spec file | | **Made a design decision** | Chose extensibility pattern over simplicity | Relevant spec + "Design Decisions" section | | **Fixed a bug** | Found a subtle issue with error handling | Relevant spec (e.g., error-handling docs) | | **Discovered a pattern** | Found a better way to structure code | Relevant spec file | | **Hit a gotcha** | Learned that X must be done before Y | Relevant spec + "Common Mistakes" section | | **Established a convention** | Team agreed on naming pattern | Quality guidelines | | **New thinking trigger** | "Don't forget to check X before doing Y" | `guides/*.md` (as a checklist item) |

**Key Insight**: Code-spec updates are NOT just for problems. Every feature implementation contains design decisions and contracts that future AI/developers need to execute safely.

---

Spec Structure Overview

.trellis/spec/
├── <layer>/           # Per-layer coding standards (e.g., backend/, frontend/, api/)
│   ├── index.md       # Overview and links
│   └── *.md           # Topic-specific guidelines
└── guides/            # Thinking checklists (NOT coding specs!)
    ├── index.md       # Guide index
    └── *.md           # Topic-specific guides

CRITICAL: Code-Spec vs Guide - Know the Difference

| Type | Location | Purpose | Content Style | |------|----------|---------|---------------| | **Code-Spec** | `<layer>/*.md` | Tell AI "how to implement safely" | Signatures, contracts, matrices, cases, test points | | **Guide** | `guides/*.md` | Help AI "what to think about" | Checklists, questions, pointers to specs |

**Decision Rule**: Ask yourself:

• "This is **how to write** the code" → Put in a spec layer directory
• "This is **what to consider** before writing" → Put in `guides/`

**Example**:

| Learning | Wrong Location | Correct Location | |----------|----------------|------------------| | "Use API X not API Y for this task" | ❌ `guides/` (too specific for a thinking guide) | ✅ Relevant spec file (concrete convention) | | "Remember to check X when doing Y" | ❌ Spec file (too abstract for a spec) | ✅ `guides/` (thinking checklist) |

**Guides should be short checklists that point to specs**, not duplicate the detailed rules.

---

Update Process

Step 1: Identify What You Learned

Answer these questions:

1. **What did you learn?** (Be specific) 2. **Why is it important?** (What problem does it prevent?) 3. **Where does it belong?** (Which spec file?)

Step 2: Classify the Update Type

| Type | Description | Action | |------|-------------|--------| | **Design Decision** | Why we chose approach X over Y | Add to "Design Decisions" section | | **Project Convention** | How we do X in this project | Add to relevant section with examples | | **New Pattern** | A reusable approach discovered | Add to "Patterns" section | | **Forbidden Pattern** | Something that causes problems | Add to "Anti-patterns" or "Don't" section | | **Common Mistake** | Easy-to-make error | Add to "Common Mistakes" section | | **Convention** | Agreed-upon standard | Add to relevant section | | **Gotcha** | Non-obvious behavior | Add warning callout |

Step 3: Read the Target Code-Spec

Before editing, read the current code-spec to:

• Understand existing structure
• Avoid duplicating content
• Find the right section for your update

cat .trellis/spec/<category>/<file>.md

Step 4: Make the Update

Follow these principles:

1. **Be Specific**: Include concrete examples, not just abstract rules 2. **Explain Why**: State the problem this prevents 3. **Show Contracts**: Add signatures, payload fields, and error behavior 4. **Show Code**: Add code snippets for key patterns 5. **Keep it Short**: One concept per section

Step 5: Update the Index (if needed)

If you added a new section or the code-spec status changed, update the category's `index.md`.

---

Update Templates

Mandatory Template for Infra/Cross-Layer Work

## Scenario: <name>

### 1. Scope / Trigger
- Trigger: <why this requires code-spec depth>

### 2. Signatures
- Backend command/API/DB signature(s)

### 3. Contracts
- Request fields (name, type, constraints)
- Response fields (name, type, constraints)
- Environment keys (required/optional)

### 4. Validation & Error Matrix
- <condition> -> <error>

### 5. Good/Base/Bad Cases
- Good: ...
- Base: ...
- Bad: ...

###