docs(scope): make Overview route canonical

SKILL.md

@@ -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.1.0
+version: 1.3.3
 author: Hermes Agent
 license: MIT
 metadata:
@@ -60,20 +60,44 @@ Record approver identity, decision evidence, date, resulting status, and conditi
 `Scope` is a top-level menu item immediately before `Architecture`, with its own dedicated sidebar:
 
 ```text
+Overview
 Roadmap
+Ideas
+  <CODE>-IDEA-1
+  ...
+Questions
+  Q-0001
+  ...
 Epics
   <CODE>-EP-1
     <CODE>-FT-1
     <CODE>-FT-2
   <CODE>-EP-2
     ...
-Ideas
 ```
 
+The project documentation's **Ways of Working** area must contain a separate first sidebar item named **Scope** explaining the ticket hierarchy, delivery statuses, exact/derived authority, roll-up, blockers, cancellation, dependencies, gates, and evidence rules.
+
 ### Roadmap
 
 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.
 
+### Overview
+
+Maintain a dedicated **Overview** page at canonical route `/scope/overview/` as the first item in the Scope sidebar. It contains the Issue Status Matrix and 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. Do not retain an `/scope/issues/` source, route, redirect, or navigation ID.
+
+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. Render exactly one semantic matrix table: it initially contains every governed record, and search/type/status controls narrow that same table. Do not add a second “complete unfiltered” disclosure or duplicate table. Keep the current table usable for print, accessibility, and no-JavaScript output. Sort deterministically by hierarchy and stable ID. Link every row to its canonical record and 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 Overview 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:
@@ -99,11 +123,81 @@ ID | Epic | user/problem statement | expected value | scope | acceptance outcome
 
 Each Epic page contains a linked Features table with current statuses. Each Feature page contains title, description, value, scope, acceptance outcomes, dependencies, risks, human approval evidence, and a linked table of authoritative Architecture tasks when they exist. Scope never creates duplicate task identities.
 
-Lifecycle states are `Proposed`, `Approved for Solution`, `Rejected`, or `Deferred`.
+Approval is a gate, not a delivery status. Preserve `Approved for Solution`, implementation approval, conditions, and decision evidence in dedicated fields and append-only histories; do not overload the item's delivery status with approval language.
 
 ### Ideas
 
-Ideas are early opportunities not yet accepted as Epics or Features. Record stable local reference, title, description, evidence/source, owner when known, status, and resulting Epic/Feature links. Preserve provenance after promotion.
+Ideas are early opportunities not yet accepted as Epics or Features. Record stable local reference, title, goal, benefit, evidence/source, owner when known, status, and resulting Epic/Feature links. Preserve provenance after promotion. The Ideas parent page and each Idea child page must be visible in the Scope sidebar and use a readable card/detail layout rather than tables.
+
+### Questions
+
+Questions are governed product decisions, separate from delivery status and approval. Keep a Questions parent page and one sidebar-visible child page per canonical Question. Show the question, why it matters, affected scope, owner, status, recorded answer when available, and evidence without using tables.
+
+Do not maintain a separate Product Register page. Overview and the canonical Epic, Feature, Idea, and Question pages are the product lookup surfaces.
+
+## Unified delivery lifecycle and roll-up
+
+Use one delivery vocabulary across Ideas, Epics, Features, and Tasks while preserving the difference between product design/delivery and task execution.
+
+Product items use:
+
+```text
+Idea, Epic, Feature: IN_BACKLOG → IN_DESIGN → IN_DELIVERY → TO_BE_RELEASED → DONE
+```
+
+Tasks use:
+
+```text
+Task: IN_BACKLOG → IN_PROGRESS → TO_BE_RELEASED → DONE
+```
+
+`CANCELLED` is an explicit exceptional terminal state for every item type. `BLOCKED` is an orthogonal flag with a reason and evidence, never a lifecycle status. Do not use `READY`, `QUEUED`, `Proposed`, `Approved for Solution`, or `Approved for Implementation` as delivery statuses.
+
+### Status meaning
+
+- `IN_BACKLOG`: retained but not actively designed or executed.
+- `IN_DESIGN`: an Idea, Epic, or Feature is actively being scoped, decomposed, or solutioned; no required implementation Task has started.
+- `IN_PROGRESS`: a Task is actively being implemented or validated.
+- `IN_DELIVERY`: implementation of a product item's governed descendant scope has started, or part of that scope is already later in the delivery chain while the complete product item has not reached `TO_BE_RELEASED`.
+- `TO_BE_RELEASED`: the complete required scope is implementation-complete and belongs to a release candidate, but release verification is not complete.
+- `DONE`: the complete required scope has passed its release boundary, or an explicitly non-releasable item has durable completion evidence.
+- `CANCELLED`: an authorized decision removed, rejected, abandoned, or superseded the item. Cancellation never means done.
+
+### Canonical relationships
+
+Maintain one validated roll-up set at each boundary:
+
+```text
+Idea    → directly resulting Epics and/or Features
+Epic    → required child Features
+Feature → required implementation Tasks
+```
+
+When an Idea points to both an Epic and one of that Epic's Features, mark only one level as a roll-up target so the same work is not counted twice. Distinguish required children from optional, removed, or superseded children. A cancelled child may be excluded only by an explicit scope decision that updates the parent's required set; never count `CANCELLED` as `DONE`.
+
+### Deterministic parent aggregation
+
+Derive Idea status from its validated direct resulting-item set, Epic status from required Features, and Feature status from required Tasks. Evaluate these rules in order:
+
+1. `CANCELLED` is never derived; it requires an explicit authorized item decision.
+2. If the required-child set is non-empty and every required child is `DONE`, the parent is `DONE`.
+3. Otherwise, if every required child is either `TO_BE_RELEASED` or `DONE` and at least one is `TO_BE_RELEASED`, the parent is `TO_BE_RELEASED`.
+4. Otherwise, if any required descendant has entered active or later execution—Task `IN_PROGRESS`, or child `IN_DELIVERY`, `TO_BE_RELEASED`, or `DONE`—the parent is `IN_DELIVERY`.
+5. Otherwise, an actively scoped, decomposed, or solutioned product item is `IN_DESIGN`.
+6. Otherwise, the parent is `IN_BACKLOG`.
+
+An item with no validated required children cannot derive `TO_BE_RELEASED` or `DONE`; require direct evidence for the exact item. A parent must never appear less advanced than an active required child. Mark every computed status with `status_source: DERIVED`; exact Task transitions and direct no-child decisions use `status_source: EXACT`.
+
+### Transition and evidence rules
+
+- Product items normally move `IN_BACKLOG → IN_DESIGN`; they move to `IN_DELIVERY` when required descendant implementation starts.
+- Tasks normally move `IN_BACKLOG → IN_PROGRESS → TO_BE_RELEASED → DONE`.
+- A Task may move directly from `IN_PROGRESS` to `DONE` only when its outcome is explicitly non-releasable or the same evidence proves implementation and release completion; record the reason.
+- Moving the final required child can trigger deterministic parent roll-up in the same canonical change, but never fabricate missing relationships or evidence.
+- Promotion does not finish an Idea. A promoted Idea remains linked to its resulting items and follows their aggregate delivery status until their required outcome is `DONE`.
+- Documentation activity, approval, CI success, merge state, deployment health, or silence alone does not advance status. Every exact transition requires actor, authority, UTC date, previous and target state, conditions, and durable evidence.
+- Keep approval, blocking, acceptance evidence, version allocation, deployment, and release records separate from lifecycle status even when they supply transition evidence.
+- Preserve append-only historical approval/lifecycle events during migration. Convert old approval-shaped status fields into approval gates and establish the new delivery status with a new evidenced event; do not rewrite history.
 
 ## React Flow visualization contract
 
@@ -135,7 +229,7 @@ Use evidence from all six same-project channels. Delivery and release outcomes m
 
 - **Scope → Architecture:** only human-approved Features with stable ID, parent Epic, value, scope, acceptance outcomes, dependencies, risks, and approval evidence.
 - **Architecture → Scope:** feasibility constraints, requirement implications, dependencies, and proposed scope clarifications; Architecture does not silently rewrite product scope.
-- **Scope → Kanban:** stable Epic/Feature identities and lifecycle state for Board/Focus reconciliation.
+- **Scope → Kanban:** stable Idea/Epic/Feature identities, required-child relationships, approval gates, and unified delivery status for Board/Focus reconciliation.
 - **Delivery/Releases → Scope:** verified outcomes, regressions, user feedback, and follow-up opportunities that may alter the Roadmap or create Ideas.
 - **Scope → General:** concise overall implications, decisions requiring visibility, owners, and cross-channel blockers.
 
@@ -144,7 +238,7 @@ Use evidence from all six same-project channels. Delivery and release outcomes m
 1. Confirm the exact project code and six approved channel IDs.
 2. Read new activity from the other five channels and enough Scope history to avoid duplication.
 3. Separate verified facts, human decisions, proposals, forecasts, and unresolved questions.
-4. Inspect Roadmap, Epics, Features, Ideas, links, IDs, lifecycle states, and approval evidence.
+4. Inspect Overview, Roadmap, Epics, Features, Ideas, Questions, links, IDs, unified delivery statuses, required-child roll-ups, and approval evidence.
 5. Reconcile architecture feasibility, Kanban flow, delivery progress, and release outcomes against scope.
 6. Add or materially improve at least one useful evidence-based artifact, or document the exact evidence/approval blocker.
 7. Load `documentation-docusaurus`, validate menu order, dedicated sidebar, hierarchy, links, and documentation build, then verify remote state.
@@ -180,16 +274,27 @@ Requires human approval for:
 8. Inspecting another project's channels.
 9. Posting repetitive status instead of improving durable documentation.
 10. Claiming completion without build and remote readback evidence.
+11. Treating approval names as delivery statuses instead of separate gates.
+12. Marking an Idea `DONE` merely because it was promoted, rather than rolling up its governed resulting items.
+13. Deriving a parent from an incomplete, duplicated, or unvalidated child set.
+14. Counting a cancelled child as done or silently excluding it without an explicit scope decision.
+15. Moving a parent to `TO_BE_RELEASED` while any required child remains in backlog, design, active delivery, or progress.
 
 ## Verification Checklist
 
 - [ ] Only the six same-project channels were inspected.
 - [ ] Scope appears immediately before Architecture with its own sidebar.
-- [ ] Sidebar order is Roadmap, Epics with nested Features, then Ideas.
+- [ ] Sidebar order is Overview, Roadmap, Ideas with child pages, Questions with child pages, then Epics with nested Features.
+- [ ] Ways of Working starts with a separate Scope page explaining the ticket hierarchy and governed statuses.
+- [ ] Ideas and Questions use table-free parent/child pages; no Product Register page exists.
 - [ ] Roadmap distinguishes verified current state from predicted plans.
 - [ ] Epics and Features use stable project-scoped IDs and valid parent-child links.
 - [ ] Every Epic links child Features; every Feature links authoritative tasks when present.
 - [ ] Ideas preserve provenance when promoted.
+- [ ] Every item uses the governed status vocabulary for its type; approval, blocking, and release evidence remain separate fields.
+- [ ] Idea, Epic, and Feature roll-ups use complete validated required-child sets with no ancestor/descendant double counting.
+- [ ] Every derived status follows the ordered aggregation rules and is labelled `DERIVED`; exact transitions are labelled `EXACT`.
+- [ ] No parent is `TO_BE_RELEASED` or `DONE` while a required child is earlier than that aggregate permits.
 - [ ] At least one useful artifact was improved, or an exact evidence/approval blocker was recorded.
 - [ ] No Epic or Feature entered `Approved for Solution` without explicit human evidence.
 - [ ] Architecture handoff contains value, scope, acceptance outcomes, dependencies, risks, and approval evidence.