docs(scope): enforce requested sidebar order

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.2.0
+version: 1.3.2
 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 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.
+
+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 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:
@@ -103,7 +127,13 @@ Approval is a gate, not a delivery status. Preserve `Approved for Solution`, imp
 
 ### 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
 
@@ -199,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.
 
@@ -208,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.
@@ -254,7 +284,9 @@ Requires human approval for:
 
 - [ ] 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.