feat: make FEATURE_ROADMAP a living doc — dev definition-of-done + audit default

Mike's decision (2026-05-27): the roadmap is a maintained status-and-plan
tracker ([ ]=planned, [x]=shipped, dated), consulted going in and updated
coming out.

- gururmm-development-principles memory: new "Living Roadmap (MANDATORY)"
  principle — consult before building, update the entry in the SAME change
  when shipping/modifying; roadmap update is part of definition-of-done.
  Dev is the primary maintainer; the audit is the backstop.
- rmm-audit skill: state the convention explicitly — the roadmap pass
  default is reconcile-and-flip (not annotate-only).

(Companion gururmm-repo changes — DESIGN.md principle + baseline checkbox
reconcile — pushed separately to the gururmm repo.)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-27 06:34:41 -07:00
parent 6381874319
commit a885b54deb
2 changed files with 20 additions and 0 deletions

View File

@@ -39,6 +39,19 @@ A complete implementation includes:
---
## Living Roadmap (MANDATORY)
`projects/msp-tools/guru-rmm/docs/FEATURE_ROADMAP.md` is the single living record of intent — where the product is going AND where it has been. It is a status-and-plan tracker, NOT a write-once backlog. Convention: `[ ]` = planned, `[x]` = shipped (annotate with date).
**Consult it going in, update it coming out — the roadmap update is part of definition-of-done:**
- **Before building:** read the feature's roadmap entry for intent/scope. New work that isn't on the roadmap gets an entry first.
- **When shipping or modifying a feature:** update its roadmap entry in the SAME change — flip `[ ]``[x]` with a date, or revise/add the item. A code change that ships or alters a roadmap feature WITHOUT touching FEATURE_ROADMAP.md is incomplete (same standard as shipping without UI).
- **Don't over-claim:** an entry's text must match what's actually built. If only part is done, keep `[ ]` and annotate the scope (e.g. "TCP probing shipped; ICMP/ARP/SNMP pending") rather than flipping.
`/rmm-audit`'s roadmap pass is the **backstop** that reconciles drift — it is not the primary maintainer. Dev work keeps the roadmap honest; the audit catches what slipped. See [[feedback_rmm_dev_is_mike]] (RMM dev is Mike's).
---
## AI-Optional Operation
GuruRMM must be fully functional without requiring AI agents (Claude, autonomous analysis tools) to operate.

View File

@@ -534,6 +534,13 @@ Apply Agent F's reconciliation to `docs/FEATURE_ROADMAP.md` — this is the road
cleanup the audit is responsible for. The roadmap is a living doc, so editing it fits
the "living docs are updated" exception to read-only.
**Convention (decided 2026-05-27):** FEATURE_ROADMAP.md is a maintained status-and-plan
tracker — `[ ]` = planned, `[x]` = shipped (dated). Dev work is the primary maintainer
(updating roadmap entries is part of GuruRMM definition-of-done — see
`gururmm-development-principles`); this audit pass is the **backstop**. So the default IS
to flip stale checkboxes (reconcile-and-flip), NOT annotate-only. Only fall back to
annotate-only if the user explicitly requests it for a given run.
- **STALE-INCOMPLETE → flip `[ ]` to `[x]`** for every item Agent F proved is shipped
end-to-end. Keep the line text; optionally append `(verified <date>)`.
- **PARTIAL → leave `[ ]`, append the scope annotation** Agent F recommends