feat: require Scope issue status matrix

This commit was merged in pull request #4.
This commit is contained in:
2026-08-18 10:12:19 -07:00
+18 -1
View File
@@ -1,7 +1,7 @@
---
name: corp-v1-channel-scope
description: "Use when operating or synchronizing a Corp v1 project's Scope channel. Owns Roadmap, Epics, Features, and Ideas; correlates all six same-project channels; proactively improves evidence-based product scope; and records human approval before work enters Architecture solution design."
version: 1.2.1
version: 1.3.0
author: Hermes Agent
license: MIT
metadata:
@@ -61,6 +61,7 @@ Record approver identity, decision evidence, date, resulting status, and conditi
```text
Roadmap
Issue Status Matrix
Epics
<CODE>-EP-1
<CODE>-FT-1
@@ -74,6 +75,22 @@ Ideas
Show verified current state and predicted plans at Epic and Feature level. Distinguish approved/current facts from forecasts and proposals. Include sequence or horizon, status, dependencies, material blockers, owner, and last evidence/update date.
### Issue Status Matrix
Maintain a dedicated **Issue Status Matrix** page directly after Roadmap in the Scope sidebar. It is the complete operational index for every governed Idea, Epic, Feature, and Task; it is not a manually curated subset and does not replace the detailed records.
Generate the matrix from the same validated canonical data and status selector used by Roadmap and Board views. Include every item, including `DONE` and `CANCELLED`, with at least:
```text
ID | type | title | direct parent/resulting scope | delivery status | EXACT/DERIVED | blocked flag/reason | owner | approval gates | required children | dependencies | release/deployment evidence | last evidenced transition | canonical record link
```
Provide type/status totals and filters, but preserve a semantic table that contains the complete unfiltered matrix for search, print, accessibility, and no-JavaScript use. Sort deterministically by hierarchy and stable ID. Link every row to its canonical record and link every relationship to the resolved target record.
Fail validation when any canonical item is absent or duplicated; a required relationship is dangling, one-sided, or double-counted; a status is invalid for the item type; `status_source` is missing or wrong; a derived status disagrees with the unified roll-up algorithm; a blocked item lacks a reason; or a transition/evidence link is not durable. The page must expose stale or contradictory states rather than silently filtering them out.
Any canonical status, relationship, gate, owner, blocker, or evidence change must update the Issue Status Matrix in the same reviewed change. Acceptance requires selector/table count parity, type/status total parity, link validation, keyboard and screen-reader access, strict production build, browser console/network health, and remote exact-head readback.
### Epics and Features
Use stable project-scoped IDs: