DevFoundry/specs/templates/spec-template.md

SPEC-000: [Feature / Bug Fix Title]

• Status: DRAFT | APPROVED | IN PROGRESS | REVISED | COMPLETED | ABANDONED
• Stack: [e.g., ASP Classic + Access MDB | C# ASP.NET Core + Postgres | PHP + SQLite]
• Target Files: [List of files to be created/modified]

---

0. Spec Creation Checklist

• Status is DRAFT before user approval.
• Target Files are listed and checked for overlap with other active specs.
• Build/test/lint commands are documented in .devfoundry/references/environments.md, or this spec explicitly records that no command exists for the affected stack.
• Database changes include current schema notes, target-engine DDL, dependent queries/views/reports, and rollback or backup steps.
• If there are no database/schema changes, record exactly: No schema changes; rollback is git revert.
• Every implementation task has a preceding test/manual-verification task and completed: <YYYY-MM-DD HH:MM> timestamp space.

1. Business Context & Goal

Why is this change being made? What is the expected business outcome?

2. Acceptance Criteria (Given / When / Then)

• AC-1: Given [precondition], when [action], then [expected result].
• AC-2: Given [invalid input], when [action], then [graceful error handling].

3. Technical Design & Contracts

• Data Model / Schema Changes: (SQL statements or Access table structural updates; if none, write exactly: No schema changes; rollback is git revert.)
• Functions / APIs / Interfaces: (state preconditions, postconditions, and invariants per Design by Contract — see .devfoundry/rules/general.md)
  • FunctionName(param1 As String, param2 As Integer) As Boolean
    • Preconditions:
    • Postconditions:
• Architecture: (web apps: confirm MVC layering — controller/model/view or the stack's equivalent — or justify a deviation)
• Error Handling Strategy:

4. Implementation Plan (Atomic Steps, TDD-ordered)

• Step 1: Prepare schema / table alterations with rollback instructions, or record No schema changes; rollback is git revert. — files: [file list] — completed:
• Step 2 (test, red): Write failing test(s) for the core business logic / backend functions (or, for legacy stacks with no test harness, write the manual verification steps for them). Confirm they fail for the right reason before proceeding — files: [test/spec file list] — completed:
• Step 3 (implementation, green): Implement core business logic / backend functions — only enough to make Step 2's tests pass — files: [file list] — completed:
• Step 4: Update UI / output views (with tests first, where automatable) — files: [file list] — completed:
• Step 5: Run the full manual or automated verification checks — files: [file list] — completed:

5. Verification & Regression Plan

• Verify AC-1 manually or via test script.
• Verify AC-2 edge-case handling.
• Check related features for regression (e.g., existing reports or queries relying on modified tables).

6. Retrospective

Filled by the Process Improver per .devfoundry/skills/process-retrospective.md, after QA approval and before archiving.

• What worked:
• Friction (rule/reference/interview gap, or none):
• Logged in .devfoundry/improvement-log.md: yes