| id | DEV-180 | ||
|---|---|---|---|
| title | Keep the Spec as Unimplemented Behavior and Graduate It | ||
| status | active | ||
| enforcement | manual | ||
| severity | error | ||
| depends_on |
|
When a Spec describes behavior that already shipped, or docs/product/
describes behavior that was never built, a reader cannot tell what the product
actually does today. The backlog and the documentation rot into fiction.
Split intended behavior from shipped behavior, and move sections across as work lands.
docs/specs/<feature>.mdholds only unimplemented behavior for a Goal.docs/product/<feature>.mdholds only what currently ships.- Each PR that delivers behavior moves the corresponding sections out of the
spec and into the appropriate file under
docs/product/. A spec may graduate into more than onedocs/product/file. - When scope is added after the Spec merges, open a new PR against the spec file and create Problem issues for the added scope.
- When every section has graduated, keep the spec file as frontmatter only.
Never delete it, so the Goal's
# Speclink keeps working.
-
docs/specs/holds only unimplemented behavior -
docs/product/holds only shipped behavior - Each shipping PR graduates the delivered sections from spec to
docs/product/ - A fully graduated spec file is kept as frontmatter only, not deleted