docs(scope): define concise reader cards

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.3.0
+version: 1.3.4
 author: Hermes Agent
 license: MIT
 metadata:
@@ -60,24 +60,31 @@ 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
-Issue Status Matrix
+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.
 
-### Issue Status Matrix
+### Overview
 
-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.
+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:
 
@@ -85,11 +92,11 @@ Generate the matrix from the same validated canonical data and status selector u
 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.
+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 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.
+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
 
@@ -114,13 +121,23 @@ Minimum Feature fields:
 ID | Epic | user/problem statement | expected value | scope | acceptance outcomes | status | owner | dependencies | risks | evidence
 ```
 
-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.
+Each Epic page uses a concise reader card showing the unified delivery status, owner, goal, benefit, problem/opportunity, constraints, clickable child-Feature tags, and original source, followed by linked Feature/task cards. Do not expose legacy aliases, decision-history tables, a separate Feature-set completeness review, or a Canonical product questions section on the reader page. Each Feature page contains title, description, value, scope, acceptance outcomes, dependencies, risks, human approval evidence, and linked authoritative Architecture tasks when they exist. Scope never creates duplicate task identities.
 
 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, source, owner when known, unified delivery 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. Reader metadata shows status and owner, not disposition; never present `Recorded`, promotion wording, or an approval gate as the delivery status.
+
+### 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, answer when available, and original source without using tables.
+
+Render affected or resulting governed records as sharp clickable tags, sorted deterministically by entity type and canonical ID. Every tag resolves the target record's canonical documentation URL; do not emit an unsorted plain list or synthesize a URL from the ID. Label reader-facing source sections **Original source**, not Evidence. For Discord sources, render each link as `Discord – <Channel name> – <Author>` while retaining the exact source-message URL.
+
+The Epic registry graph must not expose a `View accessible data table` disclosure. Keep Epic nodes keyboard-accessible, labelled, and linked to canonical records; use the detailed Epic and Feature pages as the reader surface.
+
+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
 
@@ -204,7 +221,7 @@ Use Dagre for ordinary directed graphs and ELK only for complex or grouped graph
 
 Documentation canvases are read-only. Disable mutation affordances, including `nodesDraggable={false}`, `nodesConnectable={false}`, connection creation, deletion, and accidental persistence. Preserve keyboard navigation, meaningful accessible labels and authoritative-record links, visible focus, non-color-only meaning, reduced-motion behavior, responsive controls, and sharp styling with `border-radius: 0`.
 
-Acceptance requires canonical-YAML validation, graph/table parity from the same selector, stable deterministic output, missing-reference failure or explicit warning behavior, empty/loading/error states, keyboard and screen-reader checks, no-JavaScript fallback, production build, browser console/network health, and remote exact-head verification. React Flow supplements the Roadmap, Epic/Feature records, and semantic tables; it never replaces governed Scope records.
+Acceptance requires canonical-YAML validation, graph/table parity where a semantic table is part of the intended view, stable deterministic output, missing-reference failure or explicit warning behavior, empty/loading/error states, keyboard and screen-reader checks, production build, browser console/network health, and remote exact-head verification. The Epic registry intentionally omits the expandable table disclosure and instead requires keyboard-accessible linked nodes plus canonical detail pages. React Flow supplements the Roadmap, Epic/Feature records, and semantic tables; it never replaces governed Scope records.
 
 ## Proactive Iteration Requirement
 
@@ -225,7 +242,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, unified delivery statuses, required-child roll-ups, 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.
@@ -271,7 +288,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.