docs: require direct Hermes Kanban links

Merge central Scope portal-link reporting rule

SKILL.md

@@ -1,32 +1,49 @@
 ---
 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."
+description: "Use when operating or synchronizing a Corp v1 project's Scope channel. Owns Roadmap, Epics, Features, and Ideas; correlates all seven 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.7.0
 author: Hermes Agent
 license: MIT
 metadata:
   hermes:
     tags: [corp-v1, discord, channel, scope, roadmap, epics, features, discovery]
-    related_skills: [corp-v1--main, home-v1-discord, documentation-docusaurus]
+    related_skills: [corp-v1-main, home-v1-discord, documentation-docusaurus, corp-v1-glossary]
 ---
 
 # Corp v1 Scope Channel
 
 ## Overview
 
-This skill owns product discovery and durable scope for a Corp v1 project's `scope` channel. It monitors the six same-project channels—`general`, `scope`, `architecture`, `kanban`, `delivery`, and `releases`—and maintains the project documentation's top-level **Scope** area.
+## Hermes Kanban direct-link contract
 
-Scope owns Roadmap, Epics, Features, and Ideas. General coordinates overall project awareness but does not duplicate Scope records. Architecture performs solution work only for Features explicitly approved for solution by a human team member. Hermes participates proactively by proposing and refining useful scope, but never approves its own proposals.
+Whenever a response mentions a Hermes Kanban board, initiative, card, or task, it must include a direct dashboard link in the form `[descriptive board label](<dashboard-public-url>/kanban?board=<board-slug>)`. Resolve the dashboard public URL and exact board slug before reporting; never provide only a board name, slug, card count, “visible cards,” or “available in the dashboard.” If no task-specific deep link exists, link the board and include the exact task ID or title in the same statement. Project-adopted skills must replace this generic form with their verified project board URL.
+
+This skill owns product discovery and durable scope for a Corp v1 project's `scope` channel. It monitors the seven same-project channels—`general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases`—and maintains the project documentation's top-level **Scope** area.
+
+Scope owns Overview, Roadmap, Epics, Features, canonical Task records/reader pages, Ideas, and Questions. General coordinates overall project awareness but does not duplicate Scope records. Architecture performs solution work only for Features explicitly approved for solution by a human team member and remains semantic owner of requirement/task derivation, dependencies, and readiness. Hermes participates proactively by proposing and refining useful scope, but never approves its own proposals.
 
 Load the global `documentation-docusaurus` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus` before changing documentation structure, navigation, Markdown/MDX, Docusaurus configuration, or builds.
 
+Load the global `corp-v1-glossary` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1-glossary` whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level **Glossary** area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.
+
+## Shared Corp v1 System Login
+
+When an authorized task requires login to a Corp v1 system being built or operated, follow the shared policy in `corp-v1-main` and use only the Bitwarden-injected runtime secrets named:
+
+```text
+HL_V1_SSO_EMAIL
+HL_V1_SSO_PASSWORD
+```
+
+Secret availability is capability, not authorization. Verify the destination origin and task purpose before login. Never print, inspect, log, hash, serialize, paste, screenshot, or persist either value; never place a value in a command line, URL, file, repository, prompt, Discord message, browser console, test fixture, CI output, or generated artifact. Never ask a human to paste a value into chat. If a variable is unavailable, report only its missing name and request Bitwarden/gateway injection. Login does not authorize account recovery, MFA or credential changes, permission changes, billing, spending, destructive operations, or access outside the approved project task.
+
 ## When to Use
 
 Use this skill when:
 
 - operating in `corp-v1-<code>-scope`;
 - running its recurring synchronization job;
-- maintaining Roadmap, Epics, Features, or Ideas;
+- maintaining Overview, Roadmap, Epics, Features, canonical Task reader pages, Ideas, or Questions;
 - discovering user/project problems and opportunities;
 - refining value, scope, acceptance outcomes, dependencies, or risks;
 - preparing an Epic or Feature for human `Approved for Solution` review;
@@ -42,12 +59,13 @@ Inspect only:
 corp-v1-<code>-general
 corp-v1-<code>-scope
 corp-v1-<code>-architecture
+corp-v1-<code>-ui-ux
 corp-v1-<code>-kanban
 corp-v1-<code>-delivery
 corp-v1-<code>-releases
 ```
 
-Read enough Scope history to avoid duplicates and only relevant new activity from the other five channels. Never inspect or correlate another project's channels.
+Read enough Scope history to avoid duplicates and only relevant new activity from the other six channels. Never inspect or correlate another project's channels.
 
 ## Human Approval Gate
 
@@ -60,30 +78,62 @@ 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
+  ...
 Epics
   <CODE>-EP-1
+    Questions
+      Q-0001
+      ...
+    Features
       <CODE>-FT-1
+        Tasks
+          <CODE>-TS-1
+          ...
       <CODE>-FT-2
   <CODE>-EP-2
     ...
-Ideas
 ```
 
+Within `Epics`, the exact reader hierarchies are **Epics → Epic → Questions → Question** and **Epics → Epic → Features → Feature → Tasks**. `Questions`, `Features`, and `Tasks` are explicit grouping/navigation levels, not flattened labels. Every Task has a separate canonical reader page nested under its owning Feature; no aggregate task list may substitute for those pages.
+
+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.
 
-### Epics and Features
+### Overview
 
-Use stable project-scoped IDs:
+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, Features, and Tasks
+
+Use stable project-scoped reader IDs. Keep canonical identity and reader display identity as separate fields whenever the repository data model already distinguishes them:
 
 ```text
 Epic:    <UPPERCASE_PROJECT_CODE>-EP-<NUMBER>
 Feature: <UPPERCASE_PROJECT_CODE>-FT-<NUMBER>
+Task canonical ID: TASK-<ZERO_PADDED_NUMBER>
+Task display ID: <UPPERCASE_PROJECT_CODE>-TS-<NUMBER>
 ```
 
-Allocate numbers monotonically. Never reuse or renumber an ID after rejection, deferral, deletion, or consolidation.
+Allocate reader numbers monotonically. Never reuse or renumber an Epic or Feature ID, a Task display ID, or a canonical record ID after rejection, deferral, deletion, or consolidation. Every Task requires explicit `canonical_id: TASK-<ZERO_PADDED_NUMBER>` and `display_id: <UPPERCASE_PROJECT_CODE>-TS-<NUMBER>` fields. Bind dependencies, links, event histories, evidence, and append-only hashes to `canonical_id`; use `display_id` only for reader-facing navigation and labels. Existing Task canonical IDs never change. Allocate canonical identity for new Tasks through the repository's canonical data model; never infer it from a sidebar label or display ID.
 
 Minimum Epic fields:
 
@@ -97,13 +147,35 @@ 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 its `Features` group. 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, Architecture requirement/readiness traceability, and a `Tasks` group linking every canonical child Task page.
+
+Scope is the canonical Task record and reader-page host, while Architecture remains semantic owner of task derivation, dependencies, and readiness. Kanban and Delivery own task flow and execution evidence. Synchronize those dimensions into the Scope reader without duplicating ownership or inventing transitions. Store canonical Task identity and project-scoped display identity in explicit separate fields. During display-ID migration, preserve historic canonical identities, aliases, evidence, and append-only hashes; do not rewrite historical events or hashes solely to replace a legacy display name.
 
 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
+
+RootAtSkic approved this Epic-owned Question and Idea-conversion model in [Scope message `1543962519377289226`](https://discord.com/channels/1518726359512387766/1537544173366943886/1543962519377289226) on 2026-08-31.
+
+Questions are governed product decisions, separate from delivery status and approval. A Question exists only after it can name exactly one closest owning Epic. Store that ownership as canonical `epic_id`, require `affects_ids` to include exactly one Epic and any exact affected Features from that same Epic, and validate the Epic/Feature `question_ids` relationships reciprocally. Never infer ownership from sidebar position, title similarity, or the first affected Feature.
+
+Every Epic has a `Questions` child page, including an explicit empty page when no canonical Questions are mapped. Place each Question's sidebar item and reader route beneath that one owning Epic. Do not maintain a global Questions bucket, duplicate one Question beneath several Epics, or generate links from ID conventions; links must resolve the Question's canonical nested documentation URL. When Question ownership changes, update `epic_id`, reciprocal relationships, reader route, sidebar placement, and all generated links atomically.
+
+If a question-shaped opportunity cannot be mapped honestly to an existing Epic, capture it as an Idea rather than creating a Question. Preserve the original wording and source as Idea provenance. Promote or refine the Idea into governed Epic or Feature scope first; only then create product Questions owned by that scope. A question mark does not substitute for governed ownership.
+
+Show each canonical Question's question text, why it matters, affected scope, owner, status, answer when available, and original source without using tables. Validation must fail closed for missing or unknown `epic_id`, multiple affected Epics, cross-Epic affected Features, one-sided relationships, missing Epic Questions pages, stale global Question routes, or reader/sidebar routes outside the owner Epic.
+
+Render affected or resulting governed records as a borderless vertical list of ordinary links, sorted deterministically by entity type and canonical ID. Every governed record is a separate list row containing exactly one full-surface anchor to that record's canonical documentation URL; never combine multiple IDs or links into one visual item, synthesize a URL from the ID, or surround the relationship section/link with card or tag borders. Each link shows entity type, canonical ID, title, and a directional cue, with underlining, row spacing, pointer cursor, enabled pointer events, keyboard focus treatment, and an accessible label. Validate every generated Idea page by counting separate anchors, requiring one unique valid target per row, proving every target route exists, and checking deployed HTML and CSS together. 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.
+
+Published stylesheet URLs must be derived from the actual CSS byte-content hash so changed reader CSS cannot reuse an immutable cached URL. Stage the complete Pages site, verify the staged stylesheet bytes and filename hash, and atomically replace the deployed directory; never publish by deleting the live directory and copying files into it incrementally.
+
+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
 
@@ -187,13 +259,13 @@ 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
 
 Every Scope iteration must add or materially improve at least one evidence-based scope artifact when a safe path exists: a grounded Idea, Epic, or Feature; clearer value or acceptance outcomes; dependency/risk evidence; deduplication; Roadmap reconciliation; cross-links; or a concrete unanswered product question. Never create filler to satisfy cadence.
 
-Use evidence from all six same-project channels. Delivery and release outcomes may expose new Ideas or required scope corrections; Architecture may expose infeasible assumptions; Kanban may expose flow or dependency problems. Preserve authority boundaries while incorporating that evidence.
+Use evidence from all seven same-project channels. Delivery and release outcomes may expose new Ideas or required scope corrections; Architecture may expose infeasible assumptions; Kanban may expose flow or dependency problems. Preserve authority boundaries while incorporating that evidence.
 
 ## Handoffs
 
@@ -203,16 +275,22 @@ Use evidence from all six same-project channels. Delivery and release outcomes m
 - **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.
 
+## UI/UX Coordination
+
+Scope supplies UI/UX with stable Feature identity, user problems, value, acceptance outcomes, and approval evidence. UI/UX may explore proposals but only an approved design package may become implementation-readiness evidence; Scope remains authoritative for product outcome and disposition.
+
 ## Synchronization Workflow
 
-1. Confirm the exact project code and six approved channel IDs.
+1. Confirm the exact project code and seven approved channel IDs.
-2. Read new activity from the other five channels and enough Scope history to avoid duplication.
+2. Read new activity from the other six 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, Ideas, the exact Epics → Epic → Questions → Question and Epics → Epic → Features → Feature → Tasks hierarchies, every separate Question and Task reader page, 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.
+7. Load `documentation-docusaurus` and the project CI/CD skill. Run only fast, dependency-free local preflight checks such as schema/parity scripts, targeted tests already available, `git diff --check`, and secret scanning. Do not spend the working session installing dependencies or repeatedly running the full documentation build locally when PR-triggered Gitea Actions can provide the authoritative environment.
-8. Post a concise Scope update with changed artifacts, implications, human gate, and exact evidence. Stay silent when no substantive result exists.
+8. Push the smallest coherent reviewable branch early and open or refresh its PR. The PR workflow must install dependencies and run the complete canonical-data validation, tests, typecheck, strict production build, and built-site assertions without publishing. Wait for the run attached to the exact pushed SHA; inspect failed job steps and logs, fix only evidenced defects, push, and repeat until that exact head is green.
+9. Review the exact CI-green head, merge through the repository workflow, then require default-head CI/publication success and deployed remote readback before reporting completion. Never treat a local build, a stale run, or CI for another SHA as acceptance evidence.
+10. Post a concise Scope update. When verification is successful and the human did not ask for delivery evidence, report only the substantive changes and the reader-facing documentation link; omit routine test, build, CI, audit, PR, run, commit, and SHA details. Internal validation and immutable evidence remain mandatory. Include technical evidence only when requested or when a failure, blocker, or unresolved publication state makes it actionable. Handoff packets retain their explicit evidence contract. Prefer the most specific verified documentation route, and include the portal landing page when several pages changed. If default-head publication or page-body verification is still pending, say so instead of presenting the route as published, then provide the documentation link in the completion follow-up. Stay silent when no substantive result exists.
 
 ## Authority and Escalation
 
@@ -232,32 +310,63 @@ Requires human approval for:
 - changing governance, architecture, implementation, version, or release decisions;
 - permissions, credentials, spending, external contact, or irreversible/high-impact work.
 
+
+## Mined Project-Adoption Improvements
+
+## Dedicated Project Channel Workspace
+
+Every project adoption must bind this channel to a dedicated local workspace under the active working root. Keep clones, worktrees, plans, reports, screenshots, generated artifacts, retained logs, and channel inputs inside that channel root. Use run-unique or task-specific children under `workspace/`; keep durable project truth in approved repositories. A local folder boundary organizes execution only—it neither broadens authority nor replaces remote evidence. Delivery adoptions should additionally use a channel-level `cache/` for reusable pinned toolchains and dependencies, while keeping Task evidence isolated by Task.
+
+## Project-Adoption Scope Lessons
+
+Use a stable, idempotent channel-handoff packet only after the source-owned outcome is complete and verified. The destination validates evidence and its own entry gates, processes each handoff ID at most once, and returns an incomplete packet without inferring approval. Follow [references/channel-handoff.md](references/channel-handoff.md).
+
+When unresolved product questions affect approval, make the boundary reviewable: distinguish unconditional readiness from conditional approval allowed by the active project authority contract; place exact open-question IDs on the Roadmap and the affected Epic/Feature pages; preserve conditions as Architecture risks; and never let Epic approval imply child-Feature approval. Use [references/decision-readiness.md](references/decision-readiness.md) and [references/data-backed-scope-integrity.md](references/data-backed-scope-integrity.md).
+
+When a human asks whether an Epic contains all Features required for its outcome, test the full user journey, distinguish shared acceptance expectations from independently valuable Features, preserve exclusions, and keep the result a proposal until approved. Use [references/feature-set-completeness.md](references/feature-set-completeness.md).
+
+Refine experiential requests into observable loops: entry/start, continuous user control, meaningful state change, visible feedback, outcome/failure, and replay/recovery. Keep feasibility research separate from solution selection. For Epic-wide constraints, create one canonical cross-cutting question, link it reciprocally to every affected Feature, validate both directions, and search for stale count/range assertions. Use [references/roadmap-multidimensional-state.md](references/roadmap-multidimensional-state.md) and [references/react-flow-governed-state.md](references/react-flow-governed-state.md) when the project uses data-backed readers or graphs.
+
 ## Common Pitfalls
 
 1. Treating General as the authoritative owner of Scope records.
 2. Approving a proposal because nobody objected.
 3. Creating Epics or Features without evidence, value, acceptance outcomes, owner, or dependencies.
 4. Using generic IDs instead of project-scoped stable IDs.
-5. Duplicating Architecture task records in Scope.
+5. Treating Scope's canonical Task reader pages as ownership of derivation/readiness, which remains with Architecture, or of flow, which remains with Kanban/Delivery.
 6. Mixing approved/current state with predictions in the Roadmap.
 7. Ignoring Architecture, Kanban, Delivery, or Releases evidence.
 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.
+11. Keeping a complete documentation build local by default instead of delegating dependency installation, full validation, typecheck, tests, and production build to PR-triggered Gitea Actions.
-12. Marking an Idea `DONE` merely because it was promoted, rather than rolling up its governed resulting items.
+12. Reading only a PR badge or latest run without proving the run's `head_sha` equals the pushed candidate SHA.
-13. Deriving a parent from an incomplete, duplicated, or unvalidated child set.
+13. Treating approval names as delivery statuses instead of separate gates.
-14. Counting a cancelled child as done or silently excluding it without an explicit scope decision.
+14. Marking an Idea `DONE` merely because it was promoted, rather than rolling up its governed resulting items.
-15. Moving a parent to `TO_BE_RELEASED` while any required child remains in backlog, design, active delivery, or progress.
+15. Deriving a parent from an incomplete, duplicated, or unvalidated child set.
+16. Counting a cancelled child as done or silently excluding it without an explicit scope decision.
+17. Moving a parent to `TO_BE_RELEASED` while any required child remains in backlog, design, active delivery, or progress.
+18. Flattening the reader hierarchy by placing Features directly under an Epic or Tasks outside their owning Feature's `Tasks` group.
+19. Rewriting historic canonical identities, evidence, or append-only hashes solely to adopt `<UPPERCASE_PROJECT_CODE>-TS-<NUMBER>` display IDs.
+20. Reporting a merged documentation PR as the latest work without giving the reader a direct link to the verified documentation portal page.
+21. Spamming a successful Scope completion with routine CI, test, PR, run, commit, or SHA details when the human asked only for the outcome and documentation link.
+22. Keeping a global Questions bucket, assigning a Question to several Epics, or creating a Question before one closest owning Epic exists instead of preserving the opportunity as an Idea.
+23. Moving a Question reader without atomically updating canonical `epic_id`, reciprocal `question_ids`/`affects_ids`, sidebar placement, and every canonical link.
 
 ## Verification Checklist
 
-- [ ] Only the six same-project channels were inspected.
+- [ ] Only the seven 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, then Epics; every Epic contains explicit Questions and Features groups.
+- [ ] Ways of Working starts with a separate Scope page explaining the ticket hierarchy and governed statuses.
+- [ ] Ideas use table-free parent/child pages; Questions use table-free Epic-owned parent/child pages; no global Questions bucket or 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.
+- [ ] Epics, Features, and Tasks use stable project-scoped IDs and valid parent-child links; Task display IDs use `<UPPERCASE_PROJECT_CODE>-TS-<NUMBER>`.
-- [ ] Every Epic links child Features; every Feature links authoritative tasks when present.
+- [ ] Every Epic has an explicit Questions group and Features group; every Feature has an explicit Tasks group; every Question and Task has a separate canonical Scope reader page beneath its owner.
+- [ ] Every Question has exactly one valid closest owning `epic_id`, exactly one Epic in `affects_ids`, same-Epic affected Features, reciprocal `question_ids`, and a canonical route beneath that Epic.
+- [ ] Every question-shaped opportunity without an honest existing Epic mapping is preserved as an Idea until governed scope exists.
+- [ ] Scope hosts Task readers, Architecture owns derivation/dependencies/readiness, and Kanban/Delivery own flow.
+- [ ] Display-ID migration preserves historic canonical identities, evidence, aliases, and append-only hashes.
 - [ ] 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.
@@ -267,5 +376,7 @@ Requires human approval for:
 - [ ] No Epic or Feature entered `Approved for Solution` without explicit human evidence.
 - [ ] Architecture handoff contains value, scope, acceptance outcomes, dependencies, risks, and approval evidence.
 - [ ] Documentation build, links, and remote readback passed.
+- [ ] Every latest-work update that reports a merged documentation PR includes the relevant verified documentation portal link.
+- [ ] A successful unrequested completion report contains only substantive changes and documentation links; technical delivery evidence appears only on request or for an actionable exception.
 - [ ] When React Flow is used, its graph and semantic table share one canonical-YAML selector and pass accessibility, build, browser, and remote exact-head checks.
 - [ ] Completed work includes exact message, path, commit, URL, or run evidence.

references/channel-handoff.md

@@ -0,0 +1,23 @@
+# Governed channel handoff
+
+Use this packet only after the source channel has completed and verified its owned outcome:
+
+```markdown
+### Channel handoff
+- Handoff ID: <CODE>-HO-<canonical-work-item>-<source>-<destination>-<UTC-minute>
+- State: READY | BLOCKED | RETURNED
+- Canonical work-item ID: <stable Epic, Feature, Task, or release ID>
+- Reader display ID: <project display ID or n/a>
+- Source: <source channel>
+- Destination: <destination channel mention>
+- Completed: <verified source-owned outcome>
+- Evidence: <exact messages, records, commits, PRs, CI, or artifacts>
+- Requested next action: <one destination-owned action>
+- Remaining gates/risks: <explicit list or none>
+```
+
+The destination scans for packets addressed to it, searches its own history for the exact Handoff ID, and processes each ID at most once. Before acting, it verifies the packet evidence and every destination entry gate. A valid packet is acknowledged and continued in the destination's authority boundary. An incomplete or invalid packet is returned as `BLOCKED` or `RETURNED` under the same Handoff ID with the missing condition and correct owner. A notification is never lifecycle approval.
+
+The normal forward path is `general → scope → architecture → ui-ux when applicable → kanban → delivery → releases → general`. Route directly to the actual owner when work begins later, and route backward for defects, contradictions, or missing evidence. General receives final outcomes and cross-cutting exceptions, not every routine transition. Continuations name the parent Handoff ID; never duplicate an already acknowledged transition or copy whole conversations.
+
+A project may add an event-driven dispatcher only through a separately approved project-local authorization and credential contract. The central packet contract does not authorize webhook creation, secret access, scheduler jobs, or automated destination mutation.

references/data-backed-scope-integrity.md

@@ -0,0 +1,150 @@
+# Data-backed Scope integrity and bounded review
+
+Use this checklist when unified delivery status, required-child roll-up, readiness, questions, or approval gates move into canonical YAML and generated Docusaurus components.
+
+## Canonical-state rules
+
+- Keep approval gates, unified delivery status, status source, required-child relationships, question dependencies, aliases, and readiness inputs in canonical data. Render mutable current-state claims from selectors/components rather than duplicating them in prose.
+- Historical prose may retain old IDs or states only when it is explicitly date/evidence bounded and labels old IDs as aliases. Canonical aliases must be unique and non-reusable.
+- Validate bidirectional relationships, including Epic↔question and Feature↔question links. Reject dangling IDs, one-sided links, self-dependencies, dependency cycles, and empty solution-artifact allocations.
+- Approval readiness is gate- and delivery-aware. Absence of open questions alone must not label cancelled, already approved, or actively delivered records as awaiting the wrong review.
+- Validate exact Task states against the Task enum and derive Idea/Epic/Feature states only from complete required-child sets. Reject ancestor/descendant double counting, missing required children, invalid status sources, a premature parent `TO_BE_RELEASED`/`DONE`, and cancelled children treated as complete.
+
+## Human-decision integrity
+
+A data record is not authorization merely because it contains approval-shaped fields.
+
+- Require a stable human actor identifier from an allowlisted identity provider, UTC decision date, exact item ID, exact resulting state, explicit conditions, and durable source evidence.
+- Require conditional approval to carry every still-open question ID or an equivalent explicit condition. Architecture must preserve these as unresolved risks.
+- Evidence links must use safe, reviewable schemes (normally HTTPS). Plain identifiers may be displayed as text but must not become arbitrary clickable URIs.
+- Approval evidence and the corresponding approval event must agree on actor, authority, item, gate decision, date, conditions, and evidence.
+- Rejected and deferred approval decisions also need authorized evidence. Questions changed to Answered need the answer plus actor/date/evidence; deferred questions need decision evidence.
+- Preserve approval and exact delivery provenance as append-only events. Validate event identity, sequence/continuity, current-state agreement, and tamper-evident linkage or a checked repository baseline. Never initialize empty history by deleting existing provenance.
+- Architecture-facing components must consume the same verified-approval predicate or derived field that validation uses; do not reimplement the gate as `status && approval`.
+
+## Selector parity for approval/delivery evidence and routes
+
+Generated Roadmap and current-scope selectors must fail closed with the same semantics as canonical validation:
+
+- Select the final append-only `decision_history` event (`at(-1)`), not the event with the greatest timestamp. History order is authoritative; validators may not require timestamps to be monotonic.
+- Call a decision **evidenced** only when that final event has both a valid canonical UTC date and at least one durable, renderable evidence URL. A non-empty evidence array or a plain evidence identifier is not enough.
+- Reuse or exactly mirror the canonical source-specific URL contract: parse with `URL`, require HTTPS, reject embedded credentials, and enforce the evidence-kind host allowlist. Do not test only for an `https://` prefix.
+- Validate calendar reality as well as timestamp syntax. JavaScript `Date.parse` normalizes impossible dates such as February 30; compare parsed UTC components back to the captured input components before accepting a timestamp.
+- Keep route identity canonical. Store an explicit `documentation_url` on each Epic and Feature, validate its exact stable-ID/parent-derived form, and verify that the corresponding source page exists. Selectors should consume that field rather than inventing a route for any record-shaped object.
+- Add RED-first tests for append-order versus timestamp-order, offset timestamps, impossible dates, evidence objects without URLs, source/host mismatches, credential-bearing URLs, unsafe hosts, missing documentation URLs, wrong parent paths, and absent source pages.
+
+This parity prevents a validated data model from being weakened by a more permissive presentation selector and prevents generated runtime links from bypassing static broken-link checks.
+
+## Reproducible acceptance-evidence packet consistency
+
+When operational evidence is too coarse for outcome-level acceptance classification, keep the packet contract internally executable rather than merely descriptive:
+
+- Every item declared mandatory in the prose must have its own explicit template field. In particular, record the application deployment origin URL separately from the route and scenario/preset; a route alone cannot reproduce which deployment was observed.
+- Bind the packet to two distinct immutable revisions: the canonical Scope-document revision that defines the ordered outcome set, and the tested application build/source revision. Never substitute one for the other.
+- If canonical `acceptance_outcomes` are ordered strings without stable outcome IDs, use an immutable revision-scoped ordinal reference such as `<FEATURE-ID>@<FULL-SCOPE-COMMIT>#AO-<N>`, where `N` is the one-based position in that Feature record's ordered outcome list at that exact commit. Reject an ordinal without the full Scope revision.
+- Require exactly one classification row for every canonical outcome at the recorded Scope revision. Mark coverage `complete` only when every mandatory packet field and every outcome row is present; otherwise keep it `partial` and incomplete.
+- Add durable validation markers or structural checks for newly cited evidence IDs and for the packet's reference scheme so later edits cannot silently remove the provenance or make the template unresolvable.
+- Review the required-field prose against the actual table as a pair. A full documentation build can pass while the governance contract remains impossible to complete.
+
+## Review ordering under bounded execution
+
+1. Make the smallest behavior-preserving migration.
+2. Run the full validation/build once.
+3. Stage or freeze the complete diff and dispatch an independent fail-closed review immediately—before optional polish or broadening.
+4. Apply only named blockers. Do not add unrelated schema hardening during a fix cycle.
+5. Re-run the full suite, then obtain a fresh independent verdict over the complete final diff.
+6. Only after a passing verdict proceed to commit, push, exact-head CI, and remote readback.
+
+Never edit files concurrently with a reviewer or fixer that can write to the same worktree. Wait for the agent to exit, inspect its complete diff, remove temporary migration/patch artifacts, and then continue. A background process still running at the end of the execution window means the work is incomplete: do not commit, push, or report completion.
+
+### When independent review cannot run
+
+Reviewer unavailability is not a passing verdict. Do not replace the independent review with self-review, tests, an earlier review, or successful CI from the previous remote head.
+
+Before deferring publication, try the documented isolated Hermes fallback when the main `hermes` CLI is available and authenticated. Build the prompt from the frozen complete diff in memory, pass it as a subprocess argument rather than shell-interpolating it, disable general tools with `--toolsets safe`, and require a machine-checkable final verdict:
+
+```python
+import os
+import subprocess
+
+repo = "/absolute/path/to/repository"
+base_ref = os.environ["REVIEW_BASE"]  # verified immutable SHA or intended remote base
+base = subprocess.run(
+    ["git", "-C", repo, "rev-parse", "--verify", base_ref + "^{commit}"],
+    check=True,
+    text=True,
+    capture_output=True,
+).stdout.strip()
+
+# Diffing the complete working tree against the declared base includes committed
+# branch changes plus staged and unstaged tracked changes.
+diff = subprocess.run(
+    ["git", "-C", repo, "diff", "--binary", base, "--", "."],
+    check=True,
+    text=True,
+    capture_output=True,
+).stdout
+
+# Untracked non-ignored files are not included by git diff; append each as a
+# /dev/null patch and fail closed on any unexpected return code.
+untracked_raw = subprocess.run(
+    ["git", "-C", repo, "ls-files", "-z", "--others", "--exclude-standard"],
+    check=True,
+    capture_output=True,
+).stdout
+untracked = [p.decode("utf-8") for p in untracked_raw.split(b"\0") if p]
+for path in untracked:
+    patch = subprocess.run(
+        ["git", "-C", repo, "diff", "--no-index", "--binary", "--", "/dev/null", path],
+        text=True,
+        capture_output=True,
+    )
+    if patch.returncode != 1:
+        raise RuntimeError(f"could not encode untracked path {path!r}: {patch.stderr}")
+    diff += patch.stdout
+
+inventory = subprocess.run(
+    ["git", "-C", repo, "status", "--short", "--untracked-files=all"],
+    check=True,
+    text=True,
+    capture_output=True,
+).stdout
+if not diff.strip() or not inventory.strip():
+    raise RuntimeError("review patch or changed-path inventory is empty")
+
+prompt = f"""You are an independent fail-closed reviewer.
+Review only the complete frozen patch and path inventory below at base {base}.
+Do not use tools. Do not write files.
+Return exactly PASS or BLOCK followed by actionable findings.
+Fail closed if any listed path is absent from the patch or the patch cannot be reviewed.
+
+CHANGED-PATH INVENTORY:
+{inventory}
+
+FROZEN COMPLETE DIFF:
+{diff}"""
+result = subprocess.run(
+    ["hermes", "chat", "-Q", "--toolsets", "safe", "-q", prompt],
+    cwd=repo,
+    text=True,
+    capture_output=True,
+    timeout=540,
+)
+```
+
+Treat nonzero exit, timeout, empty stdout, or anything other than an exact `PASS` or actionable `BLOCK` verdict as review failure. A `BLOCK` verdict starts a bounded fix cycle: apply only its named blockers, rerun the complete suite, freeze the new complete diff, and invoke a fresh reviewer session. Never reuse the first review after changing the patch. Do not include credentials, environment output, generated build trees, or unrelated worktree changes in the embedded prompt.
+
+If the fallback also cannot produce a valid verdict:
+
+1. Stop broadening the change after the first clean full suite.
+2. Confirm no reviewer/fixer process remains active and run `git diff --check`.
+3. Record the complete local diff hash (for example, `git diff | sha256sum`), modified-file inventory, and validation results so a later run can prove it is reviewing the same frozen patch.
+4. Re-read the authoritative PR and exact-head CI separately. State explicitly that those remote results cover only the already-pushed head, not the unpublished local patch.
+5. Leave the local patch uncommitted and unpushed. Report the review gate as the publication blocker, not as a repository or CI failure.
+6. On the next run, fetch and compare remote state before resuming. If the frozen diff or remote base changed, rerun the complete suite and require a fresh review of the new complete diff.
+
+This preserves useful work without turning a transient reviewer setup problem into false publication evidence.
+
+## Dependency audit
+
+For Docusaurus migrations that add visualization or parsing dependencies, run the production dependency audit before final review. Remediate actionable high-severity findings with a narrow supported upgrade or package-manager override, and rerun build/tests. Do not hand-edit installed `node_modules` as the durable fix.

references/decision-readiness.md

@@ -0,0 +1,69 @@
+# Scope decision-readiness pattern
+
+Use this pattern when Epics or Features in `IN_DESIGN` have open product questions and need an approval decision under the active authority contract.
+
+## Decision-readiness matrix
+
+| Item | Scope-owned open dependencies | Decision implication |
+|---|---|---|
+| `<EPIC-ID>` | `<QUESTION-IDS>` | Review Epic direction independently from child Features. Epic approval does not authorize Feature solution work. |
+| `<FEATURE-ID>` | `<QUESTION-IDS>` | Unconditional approval is not ready. A conditional approval must preserve these questions as named conditions and unresolved Architecture risks. |
+
+Keep dependency lists consistent with the canonical Epic and Feature pages. Other channels may propose additional risks, but they must not silently rewrite Scope dependencies.
+
+## Epic-page readiness block
+
+Do not leave the Epic decision boundary only in the aggregate Roadmap. On each unapproved Epic page, place a readiness block beside the approval record:
+
+```md
+No **Approved for Solution** gate is recorded for `<EPIC-ID>`. Its delivery status remains **IN_DESIGN** and unconditional approval is blocked while `<EXACT-QUESTION-IDS>` remain open.
+
+An actor permitted by the active authority contract may approve `<EPIC-ID>` conditionally, but the decision must name every unresolved question it carries forward—or an equally explicit scope condition—and Architecture must preserve those conditions as unresolved risks.
+
+The first proposed decision package is `<QUESTION-IDS>`: `<SHORT DECISION SUMMARY>`. This ordering is a proposal, not approval. Approval of this Epic would not approve any child Feature; each Feature requires its own explicit authorized decision.
+```
+
+The Epic's exact question IDs must match the Roadmap matrix and canonical question register. When no first package is justified by dependency order, omit that paragraph rather than inventing one.
+
+## Feature-page readiness block
+
+Do not leave the exact decision boundary only in the aggregate Roadmap. On each unapproved Feature page, place a short readiness block beside the approval record:
+
+```md
+No **Approved for Solution** gate is recorded. The Feature remains **IN_DESIGN** and unconditional approval is blocked while `<EXACT-QUESTION-IDS>` remain open.
+
+An actor permitted by the active authority contract may approve `<FEATURE-ID>` conditionally, but the decision must name every unresolved question it carries forward—or an equally explicit scope condition—and Architecture must preserve those conditions as unresolved risks.
+```
+
+The exact question IDs must match both the Feature's canonical dependencies and its Roadmap matrix row. A generic phrase such as "open questions remain" is insufficient for a reviewable conditional decision.
+
+## Approval evidence
+
+A valid `Approved for Solution` gate decision records:
+
+- actor identity and authority basis;
+- decision date;
+- exact stable Epic or Feature ID;
+- explicit `Approved for Solution` wording;
+- scope conditions and unresolved questions;
+- source Discord message or reviewed documentation evidence.
+
+Do not infer approval from an Epic decision, question closure, silence, documentation merge, CI result, delivery status, delivery activity, or release planning.
+
+## Conditional approval
+
+Open questions prevent unconditional readiness, but they do not prohibit an authorized actor from granting conditional solution approval. If that happens:
+
+1. Preserve every named condition in the Scope approval record.
+2. Hand the open questions to Architecture as unresolved risks.
+3. Require Architecture requirements and decisions to reference those conditions.
+4. Keep implementation, Focus admission, version, release, and deployment gates separate.
+
+## Review ordering
+
+When Scope, Architecture, Kanban, and release-readiness PRs depend on one another:
+
+1. Review the correction to the earliest authoritative layer first.
+2. Refresh downstream branches if the merge changes their base or evidence.
+3. Validate and cite CI at each new exact head SHA.
+4. Treat independent PRs independently; do not manufacture ordering where no content dependency exists.

references/feature-set-completeness.md

@@ -0,0 +1,57 @@
+# Epic feature-set completeness review
+
+Use this pattern when a human asks whether an Epic includes every Feature needed for its stated outcome, or whether its unresolved questions are documented.
+
+## Evidence boundary
+
+Assess completeness against the Epic's current intended outcome, user journey, explicit exclusions, and cited human request. Do not invent a Feature to satisfy cadence. Label the result as a Scope assessment or proposal, never approval.
+
+## Epic-page pattern
+
+Add a durable section at the point of review:
+
+```md
+## Feature-set completeness review
+
+The proposed Features form the minimum complete set for the current Epic outcome. This is a Scope assessment, not approval.
+
+| User journey outcome | Owning Feature | Why it is required |
+|---|---|---|
+| `<OUTCOME>` | [`<FEATURE-ID>`](<LINK>) | `<UNIQUE VALUE OR COVERAGE>` |
+```
+
+Then state:
+
+- which shared capabilities are acceptance expectations inside existing Features rather than standalone Features;
+- which adjacent outcomes remain explicitly outside the Epic;
+- whether evidence supports another Feature;
+- that expanding an excluded outcome requires a new or revised Scope proposal;
+- that Epic approval does not approve child Features.
+
+A completeness review should detect both gaps and duplication. Do not create separate Features for shared technical components or cross-cutting behavior unless they independently deliver user value within the Epic outcome.
+
+## Canonical-question confirmation
+
+Answer “are the questions documented?” at the decision point, not only in an aggregate registry:
+
+```md
+## Canonical product questions
+
+The unresolved product questions are recorded in the [question register](<REGISTER-LINK>). It records each stable question ID, affected items, owner, destination, status, blocker, and evidence.
+```
+
+Link the dependency-ordered resolution sequence when one exists. Reiterate that question resolution and lifecycle approval are separate records, and that conditional approval must name every unresolved question or equivalent scope condition carried into Architecture as an unresolved risk.
+
+## Validation
+
+When the repository has structural validators, add a RED-first assertion for:
+
+- the completeness-review heading;
+- the journey-to-Feature coverage table;
+- the canonical-question heading and register link.
+
+Run the targeted validator and observe the expected missing-marker failure before adding content. Then run the targeted validator, full documentation validator, type checking, link/build checks, and production build. This prevents a later edit from silently removing the human decision package while leaving the site build green.
+
+## Publication evidence
+
+Refresh the existing authoritative Scope PR rather than opening a competing change. After pushing, verify branch equality, PR head equality, authenticated artifact readback, and the newest exact-head CI task. Re-read only the authorized project channels at the end to ensure no human decision arrived during publication.

references/react-flow-governed-state.md

@@ -0,0 +1,62 @@
+# Governed React Flow state and reference integrity
+
+## Trigger
+
+Use this pattern when a documentation visualization combines Scope records with Kanban placement or renders canonical relationships as an interactive graph plus semantic fallback.
+
+## Canonical state separation
+
+Keep these fields independent:
+
+- `approval_gate`: verified Scope decision evidence such as `Approved for Solution`; it is not a delivery status.
+- `delivery_status`: the uppercase governed status for the item type.
+- `status_source`: `EXACT` for Task transitions and direct no-child decisions, or `DERIVED` for Idea/Epic/Feature required-child roll-up.
+- `blocked` plus `blocked_reason`: orthogonal delivery impediment, never a status value.
+
+The Board selector reads verified `delivery_status` and `status_source`. It must not map approval decisions to delivery, infer Task execution from documentation activity, or accept a parent aggregate computed from an incomplete child set. Show approval gate, canonical delivery status, and a separate plain-language Status basis (`Exact item evidence` or `Required-child roll-up`) in the fallback table so reviewers can detect contradictions without exposing internal source vocabulary.
+
+## Adapter-level fail-closed checks
+
+Repository-wide YAML validation is necessary but not sufficient. The graph adapter should directly resolve before layout:
+
+1. every displayed Idea, Epic, Feature, and Task, including its canonical documentation route;
+2. every Idea's direct resulting-item roll-up set without ancestor/descendant double counting;
+3. every Epic's required Features and every Feature's required Tasks;
+4. every Feature dependency;
+5. every displayed question relationship and the question record's canonical route; and
+6. every delivery status against the item-type enum plus its exact/derived source.
+
+Throw a clear error or return an explicit warning object before creating graph nodes. Never use `.filter()` to discard dangling relationships, convert an unresolved link to unlinked text, or construct a route from an ID naming convention.
+
+## Same-selector parity
+
+Build graph nodes, graph edges, legends, and semantic rows from one deterministic selector. Rows should carry resolved link objects such as `{id, url}` rather than raw IDs so the table cannot drift from graph validation. Keep React Flow mutation disabled and retain the server-rendered semantic table outside client-only rendering.
+
+## RED-first tests
+
+Add negative tests that prove the selector fails for:
+
+- missing item documentation route;
+- missing or duplicate Idea resulting-item relationship;
+- missing parent Epic;
+- incomplete required Feature or Task set;
+- missing Feature dependency;
+- missing question record or question route;
+- missing/invalid delivery status or status source;
+- a parent marked `TO_BE_RELEASED` while a required child is earlier than `TO_BE_RELEASED`;
+- a parent marked `DONE` while a required child is not `DONE`; and
+- a cancelled child silently counted as done or excluded without an explicit required-set decision.
+
+These cases protect both authority separation and deterministic aggregation: approval remains independent, while delivery roll-up is fail-closed and reproducible.
+
+## Independent review sequence
+
+A useful fail-closed reviewer prompt should explicitly ask whether:
+
+- approval evidence is being used to infer delivery status;
+- required-child roll-up follows the ordered `DONE` → `TO_BE_RELEASED` → `IN_DELIVERY` → `IN_DESIGN` → `IN_BACKLOG` rules;
+- dangling references are silently omitted;
+- fallback links are hard-coded or degraded to plain text; and
+- negative tests exercise adapter behavior rather than relying only on global validation.
+
+After any blocker fix, rerun the complete validation suite and obtain a fresh review over the complete final diff before pushing.

references/roadmap-multidimensional-state.md

@@ -0,0 +1,105 @@
+# Multi-dimensional Roadmap state
+
+Use this pattern when an Idea/Epic/Feature Roadmap must combine approval evidence, solution state, and the unified delivery status without conflating them.
+
+## Preserve orthogonal authority
+
+Do not rename or overwrite one domain's state with another domain's state. Render the dimensions separately:
+
+| Dimension | Owner | Example states |
+|---|---|---|
+| Approval gate | Scope | proposed/unapproved, `Approved for Solution`, rejected/deferred decision history |
+| Solution | Architecture | `Incomplete`, `Complete` |
+| Implementation approval | Architecture | `Approved for Implementation`, `Not verified` |
+| Unified delivery | Scope roll-up + Kanban/Delivery/Releases evidence | Product: `IN_BACKLOG`, `IN_DESIGN`, `IN_DELIVERY`, `TO_BE_RELEASED`, `DONE`; Task: `IN_BACKLOG`, `IN_PROGRESS`, `TO_BE_RELEASED`, `DONE` |
+
+`Approved for Solution` remains immutable gate evidence after solutioning. It is not a delivery status. A Roadmap that shows only the gate is incomplete, not evidence that work is blocked or delivered.
+
+## Fail-closed publication fields
+
+The browser adapter must consume verifier-derived fields, not raw approval-shaped YAML. Publish a boolean such as `implementation_approval_verified` only after the build-time verifier binds the exact item, state, actor/authority, UTC decision time, evidence, conditions, immutable history, and baseline. Mutation-test the decision hash/evidence/actor so the public field becomes false.
+
+Continue to consume only verifier-admitted exact Task status and validated required-child relationships for unified delivery roll-up.
+
+## Aggregate delivery
+
+An Idea, Epic, or Feature displays a required-child roll-up without inventing an exact parent transition:
+
+1. Validate one direct roll-up set: Idea → resulting Epics/Features, Epic → required Features, Feature → required Tasks. Do not count an Epic and its descendant Feature for the same Idea outcome.
+2. Preserve exact Task states and direct no-child decisions with `status_source: EXACT`; mark every product roll-up `status_source: DERIVED`.
+3. Evaluate required children in this order:
+   - all non-empty children `DONE` → parent `DONE`;
+   - otherwise all children in `{TO_BE_RELEASED, DONE}` with at least one `TO_BE_RELEASED` → parent `TO_BE_RELEASED`;
+   - otherwise any descendant in active or later execution → parent `IN_DELIVERY`;
+   - otherwise actively scoped/solutioned → parent `IN_DESIGN`;
+   - otherwise parent `IN_BACKLOG`.
+4. Never derive `CANCELLED`. Exclude a cancelled child only after an explicit Scope decision updates the required set.
+5. Keep the internal `status_source` typed, but never expose `DERIVED`, `EXACT`, or `(derived)` as reader status text. Render the canonical uppercase status unchanged and a separate **Status basis** value: `Required-child roll-up` or `Exact item evidence`.
+
+Never infer delivery from approval alone. Never let unverified raw Task state or an incomplete child set influence an aggregate.
+
+### Status-basis parity probe
+
+Roadmap and Board/Focus often render through different label paths: Roadmap may read `executionState`, while lane views read `flowState`. Probe both paths after loading, validating, and publishing the real canonical database:
+
+1. Build Roadmap, Board, and Focus from the same public database.
+2. Select one aggregate Epic, one aggregate Feature, and one exact task.
+3. Assert the Epic and Feature expose the expected canonical state plus `Required-child roll-up` in rows, nodes, and accessible labels.
+4. Assert the exact Task exposes the expected canonical state plus `Exact item evidence`.
+5. Assert reader text contains no `(derived)`, `DERIVED`, or `EXACT` status labels while internal source flags remain correct.
+
+Checking state equality alone is insufficient: `IN_DELIVERY` can be correct while its status basis is missing or misleading.
+
+## Epic solution and implementation summaries
+
+For an active Epic:
+
+- report solution complete only when every active child Feature has a complete canonical solution package;
+- report implementation readiness as an aggregate such as `All active Features Approved for Implementation` only when every child Feature's implementation decision verifies;
+- do not fabricate an Epic-level Architecture decision when only Feature decisions exist.
+
+## Presentation contract
+
+Each Roadmap node and same-adapter semantic row should expose:
+
+- approval gate;
+- solution status;
+- implementation approval;
+- canonical unified delivery status and separate plain-language Status basis.
+
+Explain the dimensions before the visualization. Remove or explicitly date stale prose such as `Delivery has not started`; generated current state supersedes historical execution assertions without rewriting the historical checkpoint.
+
+Visual QA is a governance check, not cosmetic polish:
+
+- initial fit must show every node fully;
+- all state values must be legible without mandatory first-use panning/zooming;
+- graph and table values must match;
+- no clipping or overflow;
+- preserve square styling (`border-radius: 0`).
+
+A wide left-to-right dependency chain can force unreadable 25% zoom. Prefer a top-to-bottom governed sequence when it keeps the complete graph visible at a readable scale. Put fit options in tested adapter output rather than an untested component literal.
+
+## Cross-surface reconciliation
+
+A Roadmap fix is incomplete until every sibling surface that repeats or interprets the same state has been checked. Sweep canonical Task evidence, required-child relations, Roadmap graph/table, Kanban Board and Focus prose, Architecture handoff pages, Delivery and release-readiness pages, and their prose-contract tests. Generated current-state components do not neutralize contradictory static prose below them.
+
+Preserve immutable admission and approval events as explicitly dated historical snapshots. Add verifier-derived unified delivery beside them rather than rewriting their original conditions. When Releases establishes that an exact source revision was deployed, update mutable evidence summaries with the exact source, GitOps revision, and durable Releases evidence; move governed items only when the transition and roll-up rules are satisfied.
+
+When YAML evidence prose contains `#`, do not use an unquoted plain scalar: `Application PR #5 ...` parses as only `Application PR`. Use a folded or quoted scalar and add a loader test against the parsed value so the decisive revision/message markers cannot be silently discarded.
+
+## RED-GREEN regressions
+
+Add tests before adapter or reconciliation changes:
+
+- verified implementation decisions publish true; a hash/evidence mutation publishes false;
+- an active Task derives Feature, Epic, and linked Idea `IN_DELIVERY`;
+- backlog-only required children derive `IN_BACKLOG` unless the product item has exact `IN_DESIGN` evidence;
+- all required children `TO_BE_RELEASED`/`DONE` derive `TO_BE_RELEASED` when at least one remains `TO_BE_RELEASED`;
+- all required children `DONE` derive `DONE`;
+- cancelled children fail aggregation until an explicit Scope decision updates the required set;
+- raw/unverified status does not render;
+- graph nodes, semantic rows, Board, and Focus agree;
+- Roadmap fit/layout configuration prevents initial clipping;
+- real production pipeline probe: `loadDatabase -> validateDatabase -> publicDatabase -> Roadmap/Board adapter` prints the exact state tuple for every rendered Epic/Feature.
+
+Run full validators, TypeScript, strict build, browser QA, independent fail-closed review, exact-head CI, merge, and integrated-head CI before calling the correction published.