The Gitea issue body is the single source of truth for a spec; the only per-feature artifact in git is the RTM row (REQ-ID -> issue # -> test). Drops per-feature spec.md/tasks.md/checklist files from the workflow (the _example stays as a template/reference). Updates the guide, ADR-041, AGENTS.md, CLAUDE.md, templates, the RTM (adds an Issue column), the implement/review-pr skills, and replaces the file-spec CI jobs with an rtm-check. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
82 lines
2.7 KiB
Markdown
82 lines
2.7 KiB
Markdown
---
|
||
name: "Feature (SDD spec)"
|
||
about: "Spec-driven feature request. Fill in EARS requirements before implementation starts."
|
||
title: "As a <role> I want <capability> so <reason>"
|
||
labels:
|
||
- spec-required
|
||
- needs-review
|
||
assignees: []
|
||
---
|
||
|
||
<!--
|
||
This issue body IS the spec (issue-only — there is no committed spec.md). Every requirement
|
||
uses an EARS pattern + a REQ-NNN id. Reference: .specify/templates/feature-spec.md and the
|
||
worked example .specify/features/_example/. Delete the placeholder hints as you fill each section.
|
||
-->
|
||
|
||
## Context & Why
|
||
|
||
<Who needs this and why now (2–4 sentences). Link the constitution principle(s) this depends on: .specify/constitution.md>
|
||
|
||
## User Journey
|
||
|
||
<Plain-prose steps the user takes to get value, from the user's perspective. Anything not here is out of scope.>
|
||
|
||
## Requirements
|
||
|
||
<!-- One per line, each REQ-NNN + one EARS pattern. A mutating feature needs at least one Event-driven and one Unwanted-behavior requirement. -->
|
||
|
||
- **REQ-001** (Ubiquitous) — The `<component>` shall `<always-true behavior>`.
|
||
- **REQ-002** (Event-driven) — When `<trigger>`, the `<component>` shall `<response>`.
|
||
- **REQ-003** (State-driven) — While `<state>`, the `<component>` shall `<behavior>`.
|
||
- **REQ-004** (Optional-feature) — Where `<caller has Permission.X / flag set>`, the `<component>` shall `<behavior>`.
|
||
- **REQ-005** (Unwanted-behavior) — If `<undesired condition>`, then the `<component>` shall `<safe response / ErrorCode>`.
|
||
|
||
## Acceptance Criteria
|
||
|
||
<!-- One measurable criterion per REQ-NNN: numbers, limits, status codes — not adjectives. -->
|
||
|
||
- **REQ-001** — <measurable>.
|
||
- **REQ-002** — <measurable>.
|
||
|
||
## Out of Scope
|
||
|
||
- <The nearest tempting scope creep, named and excluded.>
|
||
|
||
## API / Contract Stub
|
||
|
||
<Inline OpenAPI stub (use .specify/templates/api-contract-stub.md as a writing aid). Name new paths/methods/status codes and the @RequirePermission on each mutating endpoint.>
|
||
|
||
## Data Model Changes
|
||
|
||
<Schema delta + next free Flyway V<n> (verify on disk) + rollback note. "none" if not applicable.>
|
||
|
||
## Security Considerations
|
||
|
||
<STRIDE categories touched (+ ASTRIDE if an AI agent/tool is involved). Link a threat-model.md if the attack surface is non-trivial.>
|
||
|
||
## Open Questions
|
||
|
||
<!-- Each item BLOCKS implementation until resolved. -->
|
||
|
||
- [ ] <question> — owner: <name>
|
||
|
||
## Traceability
|
||
|
||
| REQ-ID | Task ID(s) | Test ID(s) | Status |
|
||
|---|---|---|---|
|
||
| REQ-001 | | | Planned |
|
||
|
||
<!-- Mirror these rows into .specify/rtm.md. -->
|
||
|
||
## Persona Review Results
|
||
|
||
| Persona | Status | Key Findings | Resolved |
|
||
|---|---|---|---|
|
||
| Requirements Engineer | PENDING | | |
|
||
| Developer | PENDING | | |
|
||
| Security | PENDING | | |
|
||
| DevOps | PENDING | | |
|
||
| UI/UX | PENDING | | |
|
||
| Architect | PENDING | | |
|