Adds .gitea/ISSUE_TEMPLATE/{feature,bug}.md (the feature template mirrors the
EARS feature-spec) and .gitea/workflows/sdd-gate.yml — spec-lint, contract
validation (Spectral), traceability check (all non-blocking during adoption),
and a constitution-impact PR comment.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
83 lines
2.7 KiB
Markdown
83 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 is a Spec-Driven feature spec. Mirror it to .specify/features/<name>/spec.md once the
|
||
feature has a working name. 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 stub or link to .specify/features/<name>/api-contract.yaml. 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 | | |
|