srs-authoringlisted

# SRS Authoring Transforms stakeholder input, prototypes, or module ideas into a structured, implementable requirements document. ## Inputs 1. Problem statement and target users 2. Constraints (stack, timeline, tenancy, compliance) 3. Prototype or mock links (visual reference only — not architecture) 4. Existing SRS (if updating) or greenfield scope ## Steps 1. **Gather and clarify** — actors, scope boundaries, compliance rules; ask focused questions 2. **§1 Purpose & Scope** — in / out / designed-for-not-built / definitions 3. **§2 Actors & permissions** — roles, permission keys, self-service scoping, enforcement layer 4. **§3 Functional requirements** — stable `FR-{MODULE}-{N}` IDs with acceptance criteria 5. **§4 Non-functional requirements** — audit, security, performance (`NFR-*`) 6. **§5 Data model sketch** — indicative entity list with relationships 7. **§6 Invariants** — numbered, testable rules → sync to `domain-invariants.mdc` / `CLAUDE.md` 8. **§7 Phased delivery** — explicit dependencies for `@project-planner` 9. **§8 Open decisions** — TBD table with options; never guess 10. **§9 Technical constraints** — stack, auth model, background jobs 11. **Hand off** — `@tech-lead` (architecture review) → `@project-planner` when FR IDs stable ## Critical rules - No implementation code in SRS - Stable FR IDs — never renumber without traceability note - Every invariant must be testable (audit, immutability, scope check) - Approved ≠ Paid-style status rules documented e