You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stories are tracked in two places: `docs/features.md` (the stakeholder-facing, stable record) and
24
+
GitHub issues (the implementation tracking record). When a story moves from draft (discussion in
25
+
SharePoint Word doc) to approved (ready for implementation), it receives a stable Story ID and is
26
+
documented in both locations simultaneously. See **§11.1 Story Lifecycle** for the full workflow.
27
+
23
28
-**PRD** defines product vision, user personas, and business objectives.
24
29
-**Features** group related Stories under a named, user-visible capability. A Feature references one or more requirement IDs and describes the high-level scope.
25
30
-**Stories** describe user-facing workflows derived from a Feature. Each Story references a parent Feature and one or more requirement IDs.
@@ -92,6 +97,33 @@ Where:
92
97
93
98
---
94
99
100
+
### Story ID Schema
101
+
102
+
Stories are identified using a short, human-readable slug derived from their parent Feature:
103
+
104
+
FEAT-<SLUG>-<NN>
105
+
106
+
Where:
107
+
108
+
-**SLUG** --- a concise, abbreviated identifier derived from the parent Feature slug (e.g., `IP-MEAS` for `FEAT-IMMUNOPEPTIDOMICS-MEASUREMENT`). Abbreviations must be short enough for readability but descriptive enough to be self-explanatory within the Feature context.
109
+
-**NN** --- sequential number, zero-padded to exactly two digits (e.g., `01`, `02`, `10`).
110
+
111
+
#### Examples
112
+
113
+
FEAT-IP-MEAS-01
114
+
FEAT-IP-MEAS-05
115
+
FEAT-SAMPLE-03
116
+
117
+
#### Rules
118
+
119
+
- Story IDs are assigned when a story moves from draft (discussion/refinement) to approved (ready for implementation).
120
+
- Story IDs must be stable and must never be renumbered.
121
+
- Tasks reference stories by their stable ID, not by GitHub issue number.
122
+
- GitHub issues for stories are updated to carry the stable story ID in the title and body.
123
+
- Abbreviated slugs must be unique within their parent Feature, but do not need to be globally unique across Features.
124
+
125
+
---
126
+
95
127
### Requirement Structure
96
128
97
129
All requirements must be documented in `docs/requirements.md`.
@@ -200,15 +232,37 @@ Rules:
200
232
201
233
- Tasks must not redefine acceptance criteria.
202
234
- Tasks must not expand requirement scope.
235
+
- Tasks reference stories by their stable ID (e.g., `FEAT-IP-MEAS-01`), not by GitHub issue number.
236
+
237
+
---
238
+
239
+
#### Story Lifecycle
240
+
241
+
Stories move through a lifecycle from draft to implementation. This flow keeps the GitHub issue history clean and ensures stakeholders have a stable, reviewable document.
242
+
243
+
1.**Draft (Discussion)** — The story is captured in a SharePoint Word document or similar internal medium where discussion, refinement, and iteration happen. No stable ID is assigned. The story is not yet tracked in `docs/features.md`.
244
+
2.**Approved (Ready for Implementation)** — The story is finalised, a stable `FEAT-<SLUG>-<NN>` ID is assigned, and it is:
245
+
- Written into `docs/features.md` with full narrative and acceptance criteria
246
+
- A GitHub issue is created (if it does not already exist) or an existing issue is updated with the stable ID in the title and body
247
+
- The status in `docs/features.md` is updated from 🔴 (Open) to 🟡 (In Progress) when implementation begins, and 🟢 (Done) when complete
248
+
3.**Implementation** — Tasks are created in GitHub referencing the stable story ID (not the GitHub issue number). Implementation traces: Task → Story (stable ID) → Feature → Requirement → PRD.
249
+
250
+
**Rules:**
251
+
252
+
- A story must never be implemented without a stable ID in `docs/features.md`.
253
+
- When a story was created on GitHub before this flow existed (e.g., old issue numbers), update the existing issue with the stable ID rather than creating a new one.
254
+
- Tasks reference stories by their stable ID in the "Parent Story" field, not by GitHub issue number.
255
+
- The GitHub issue remains the source of truth for implementation tracking (comments, sub-issues, assignees), but `docs/features.md` is the source of truth for story content (narrative, acceptance criteria).
203
256
204
257
---
205
258
206
259
#### Feature, Story, and Task Sequencing
207
260
208
261
- A Feature must be created before any Story references it. Create the Feature first.
209
262
- A Story must always reference a parent Feature. Never create a Story without a parent Feature issue.
210
-
- A Task must always be preceded by a Story. Create the Story first, then create the Task referencing it.
211
-
- Never create a Task without a parent Story issue.
263
+
- A Story must receive a stable `FEAT-<SLUG>-<NN>` ID before any Task is created for it.
264
+
- A Task must always be preceded by a Story. Create the Story first (draft → approved → stable ID), then create the Task referencing the stable story ID.
265
+
- Never create a Task without a parent Story issue. Tasks must reference the story by its stable ID.
212
266
- If no parent Feature exists for a piece of work (e.g., when acting on a direct implementation request), create the Feature first, then the Story, then the Task.
213
267
- A single Story may have multiple Tasks; a Task must not span multiple Stories.
214
268
@@ -621,6 +675,14 @@ When working on this codebase, an AI agent should:
621
675
- A Feature slug (`FEAT-<SLUG>`) must be unique and must not be changed once Stories reference it.
622
676
- If you are unsure whether a new Feature is needed or an existing Feature should be extended, pause and ask a human reviewer.
623
677
678
+
### Creating Stories
679
+
680
+
- Stories start as drafts (discussion/refinement in SharePoint Word or similar internal medium). They are NOT tracked in `docs/features.md` or GitHub while in draft.
681
+
- When a story is finalised and approved for implementation: assign a stable `FEAT-<SLUG>-<NN>` ID, write it into `docs/features.md` with full narrative and acceptance criteria, and create or update the corresponding GitHub issue with the stable ID in the title and body.
682
+
- For stories that were created on GitHub before this workflow existed, update the existing issue with the stable ID rather than creating a new one.
683
+
- Tasks reference the story by its stable ID (e.g., `FEAT-IP-MEAS-01`), not by GitHub issue number.
684
+
- If you are unsure whether a new Story is needed or an existing Feature should be extended, pause and ask a human reviewer.
685
+
624
686
### Making domain changes
625
687
626
688
- New domain concepts go in `domain/model/` of the relevant bounded context.
@@ -679,11 +741,13 @@ An agent should pause and request human review/approval before:
679
741
|---|---|
680
742
|`docs/requirements.md`| Authoritative requirement registry — all R/NFR/C requirements documented here; must be updated before new capabilities are implemented |
681
743
|`docs/requirements-guide.md`| Authoring conventions for creating, editing, and retiring requirements |
744
+
|`docs/features.md`| Stakeholder-facing features and user stories tracker — stable story records with narrative, acceptance criteria, and status; stories move here from draft once approved |
682
745
|`README.md`| Setup, configuration reference, how to run |
683
746
|`ExceptionHandling.md`| Exception handling conventions (read before touching error handling) |
684
747
|`service_api.md`| Service API design patterns (Mono/Flux, request/response shapes) |
0 commit comments