docs: reference shared channel workspace standard

Merge central Scope portal-link reporting rule

SKILL.md

@@ -1,32 +1,47 @@
 ---
-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.5.1
+name: channel-scope-skic
+description: "Use when operating or synchronizing a Corp v1 project's Scope channel. Owns Roadmap, Epics, Features, and Ideas; correlates all eight same-project channels; proactively improves evidence-based product scope; and records human approval before work enters Architecture solution design."
+version: 1.8.1
 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, corp-v1--glossary]
+    related_skills: [channel-board-skic, home-v1-discord, documentation-docusaurus, corp-v1-glossary]
 ---
 
-# Corp v1 Scope Channel
+# SKIC Scope Channel Reference
 
 ## 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
+
+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 eight same-project channels—`general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, `uat`, 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.
+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 `channel-board-skic` 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`;
+- operating in `<code>-scope`;
 - running its recurring synchronization job;
 - maintaining Overview, Roadmap, Epics, Features, canonical Task reader pages, Ideas, or Questions;
 - discovering user/project problems and opportunities;
@@ -38,18 +53,22 @@ Do not use it to design architecture, approve solution entry, approve implementa
 
 ## Approved Information Boundary
 
+Follow the eight-channel topology in `channel-board-skic`, approved by Board message `1552966246591365123`; include UAT between Delivery and Releases. Verify mapped IDs and effective access before reading.
+
 Inspect only:
 
 ```text
-corp-v1-<code>-general
-corp-v1-<code>-scope
-corp-v1-<code>-architecture
-corp-v1-<code>-kanban
-corp-v1-<code>-delivery
-corp-v1-<code>-releases
+<code>-general
+<code>-scope
+<code>-architecture
+<code>-ui-ux
+<code>-kanban
+<code>-delivery
+<code>-uat
+<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 seven channels. Never inspect or correlate another project's channels.
 
 ## Human Approval Gate
 
@@ -67,11 +86,11 @@ Roadmap
 Ideas
   <CODE>-IDEA-1
   ...
-Questions
-  Q-0001
-  ...
 Epics
   <CODE>-EP-1
+    Questions
+      Q-0001
+      ...
     Features
       <CODE>-FT-1
         Tasks
@@ -82,7 +101,7 @@ Epics
     ...
 ```
 
-Within `Epics`, the exact reader hierarchy is **Epics → Epic → Features → Feature → Tasks**. `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.
+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.
 
@@ -97,9 +116,11 @@ Maintain a dedicated **Overview** page at canonical route `/scope/overview/` as
 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
+ID | type | title | direct parent/resulting scope | delivery status | Status basis | blocked flag/reason | owner | approval gates | required children | dependencies | release/deployment evidence | last evidenced transition | canonical record link
 ```
 
+Keep `status_source: EXACT`/`DERIVED` internal; render **Status basis** as `Exact item evidence`/`Required-child roll-up`, separate from the unchanged canonical status.
+
 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.
@@ -143,7 +164,15 @@ Ideas are early opportunities not yet accepted as Epics or Features. Record stab
 
 ### 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.
+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.
 
@@ -241,28 +270,38 @@ Acceptance requires canonical-YAML validation, graph/table parity where a semant
 
 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 eight 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.
+
+### Acceptance-gap discovery
+
+When verified implementation or deployment precedes item-specific approval, record an acceptance gap, not retroactive approval. Attribute channel reports as reports unless independently verified. For each canonical outcome classify only `demonstrated`, `contradicted`, or `not demonstrated by the cited evidence`; missing evidence does not prove an outcome was untested. Bind coverage to the immutable Scope revision defining the outcome set and the distinct tested application revision; require one row per outcome and all capture fields before calling coverage complete. Re-evaluate completeness when Scope changes. Follow the packet contract in [data-backed Scope integrity](references/data-backed-scope-integrity.md#reproducible-acceptance-evidence-packet-consistency).
+
+Keep newest published source and actually deployed/tested source distinct. Never transfer runtime observations to a newer unobserved revision. Discovery, capture completion, healthy deployment and documentation merge do not grant acceptance, admission, release approval or lifecycle transitions.
 
 ## Handoffs
 
 - **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 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.
+- **Delivery/UAT/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.
-2. Read new activity from the other five channels and enough Scope history to avoid duplication.
+1. Confirm the exact project code and eight approved channel IDs.
+2. Read new activity from the other seven channels and enough Scope history to avoid duplication.
 3. Separate verified facts, human decisions, proposals, forecasts, and unresolved questions.
-4. Inspect Overview, Roadmap, Ideas, Questions, the exact Epics → Epic → Features → Feature → Tasks hierarchy, every separate Task reader page, 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` 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. 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 with changed artifacts, implications, human gate, exact PR/head/run evidence, and deployed readback. Stay silent when no substantive result exists.
+8. Satisfy any required pre-publication review before push; the early-PR workflow does not waive the independent review required for data-backed migrations. If a required pre-publication channel record cannot be delivered in this execution context, keep the candidate local and report that precise publication block. 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 complete candidate diff against its verified base, including older committed changes and untracked candidate files. Keep a claim ledger for dynamic source, PR, CI and runtime assertions; evidence-through times must cover every cited source within their stated boundary. Fix actual artifact defects, but correct missing ledger evidence without churning already-correct prose. Preserve the required review type: self-review is not a substitute for independent review. Merge only with applicable authorization, then require default-head CI/publication success and deployed page-body readback. A redirect to an identity-provider login page with HTTP 200 is not content verification; report that boundary rather than claiming publication verified. Never transfer a review to a changed base merely because the patch hash is unchanged.
+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
 
@@ -282,6 +321,25 @@ 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.
+
+Source comparison and exclusions: [AeroSim lessons review](references/aerosim-lessons-review.md).
+
 ## Common Pitfalls
 
 1. Treating General as the authoritative owner of Scope records.
@@ -303,17 +361,23 @@ Requires human approval for:
 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 eight same-project channels were inspected.
 - [ ] Scope appears immediately before Architecture with its own sidebar.
-- [ ] Sidebar order is Overview, Roadmap, Ideas with child pages, Questions with child pages, then the exact Epics → Epic → Features → Feature → Tasks hierarchy.
+- [ ] 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 and Questions use table-free parent/child pages; no Product Register page exists.
+- [ ] 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, Features, and Tasks use stable project-scoped IDs and valid parent-child links; Task display IDs use `<UPPERCASE_PROJECT_CODE>-TS-<NUMBER>`.
-- [ ] Every Epic has an explicit Features group; every Feature has an explicit Tasks group; every Task has a separate canonical Scope reader page.
+- [ ] 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.
@@ -325,5 +389,20 @@ 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.
+
+## Canonical naming and compatibility
+
+- Canonical installed and repository name: `channel-scope-skic`.
+- Source: `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/channel-scope-skic`.
+- Previous name: `corp-v1-channel-scope`; retained locally only as a compatibility alias. New guidance and presentations use the canonical name.
+- Naming-only migration authorized by RootAtSkic in [presentation message 1562523679223578705](https://discord.com/channels/1518726359512387766/1543922127898415154/1562523679223578705). Repository ID, history, support files, project authority and organization ownership are preserved.
+- This is a reusable central reference, not a new shared Discord channel. Project adoptions use `channel-scope-skic-<code>` and remain separately owned.
+- Current project channel: `<code>-scope` inside `skic-<code>`.
+
+## Channel workspace standard
+
+Load `channel-workspace-organization` for channel setup, file placement, and authorized workspace migration. Canonical standard: https://gitea.lego-cloud.eu/global-skills/channel-workspace-organization . Follow that shared policy rather than duplicating it here. Existing workspace bindings below remain current until an authorized migration is completed and verified; this reference alone does not relocate files or change bindings.

references/aerosim-lessons-review.md

@@ -0,0 +1,32 @@
+# AeroSim lessons review — scope
+
+## Evidence boundary
+
+Source repository: [corp-v1-aerosim-skills-code-agent/channel-scope-skic-aerosim](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-scope-skic-aerosim)
+
+Source commit: `3eb7a2a530d63e4ad20f7bff36cf435dc98eb7d6` (branch `test`, pinned clone; not the earlier adoption-base SHA).
+
+Central baseline: `602b1a0afdac56f4b8a10def4bd241b53495c3e3`. Reviewed the full source package: `SKILL.md`, `ADOPTION.md`, and `references/data-backed-scope-integrity.md`, `references/decision-readiness.md`, `references/feature-set-completeness.md`, `references/react-flow-governed-state.md`, `references/roadmap-multidimensional-state.md`. All existing source reference files were byte-identical to central at baseline; changes below address omissions or contradictions, not wholesale copying.
+
+The installed `channel-scope-skic-aerosim/SKILL.md` was also compared read-only. Runtime SHA-256: `78d2e5c1a192184cf2edd6d056182631297a9f1cb97e18cffbc402399c215b47`. Runtime differs from the pinned repository and has no verified source commit for its local-only changes; it is observation, not remote or Board approval evidence. This delegated review did not change any installed package or AeroSim/other project copy. The coordinating session owns authorized central publication and central runtime refresh.
+
+Review authority: Board-owner request message `1562171939961966693` authorizes central reference improvement and remote publication; the coordinating session also owns the authorized central runtime refresh. Central source publication must be verified before refreshing its installed package. No project adoption, project permission/authority expansion or naming migration is authorized.
+
+## Adopted lessons
+
+- `SKILL.md` → **Proactive Iteration Requirement**, acceptance-gap paragraphs: distinguish observed outcomes from missing evidence; bind exhaustive coverage to Scope and tested-application revisions; never transfer observations to newer source or manufacture retroactive approval. Existing `references/data-backed-scope-integrity.md` → **Reproducible acceptance-evidence packet consistency** remains the detailed contract.
+- `SKILL.md` → **Synchronization Workflow**, step 8 and its review-ledger, temporal-consistency and continuation bullets; step 9: review the complete candidate with a dynamic claim ledger, invalidate review after base drift, distinguish a login-page HTTP 200 from deployed-content verification. Retain central independent review, not AeroSim self-review substitution. Resolve central early-push wording against the existing pre-publication migration review gate.
+- `SKILL.md` → **Overview** (under Documentation Contract), **Roadmap**, and **React Flow visualization contract**: use plain-language Status basis rather than internal EXACT/DERIVED reader labels, matching the already-shared roadmap reference.
+- `SKILL.md` → **Epics, Features, and Tasks** forbids duplicate completeness sections, while **Human Decision Readiness** and `references/feature-set-completeness.md` still prescribe them. Resolve the central contradiction by retaining the review mechanics in a linked governed review artifact, not restoring forbidden reader sections or a global Question bucket.
+
+## Exclusions
+
+No Jira mandate, API recovery operations, release-instance migration, cumulative release schema, named owners, org-wide PR sweep, standing merge authority, self-review downgrade, dispatcher path/credentials or additional channel authorization is adopted. Runtime-only **Documentation Contract** changes to a release-first sidebar were inspected and excluded; runtime also has seven/eight-channel and UAT-route inconsistencies. Central navigation, stable identities, human decisions and independent review remain authoritative. No release-first adoption or naming migration is authorized by this review.
+
+## Central topology authority
+
+The coordinating review record `GUILD-IMP-20261020-aerosim-reference-lessons` confirms central-only maintenance. `channel-board-skic` v4.5.0, **Board Authority** / **Naming Model** / **Hermes access and Corp project automation policy**, records Board message `1552966246591365123` approving eight lifecycle channels, with UAT between Delivery and Releases. Align ordinary synchronization and references to that existing policy. Historical seven-channel bootstrap overrides are not widened; only separately reauthorized overrides may add UAT. Runtime seven-channel wording is stale, not promoted authority.
+
+## Verification
+
+Run `python3 -B -m unittest discover -s tests -v` from this repository and `git diff --check`. Tests validate normative documentation contracts and linked files offline; they do not claim live workflow, CI, deployment or remote publication verification.

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 → uat → 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,21 @@
+# Epic feature-set completeness review
+
+Use when a human asks whether an Epic covers its outcome or its product questions are documented.
+
+## Evidence boundary
+
+Assess the current intended outcome, full user journey, explicit exclusions and cited request. Label the result a proposal, never approval. Shared technical capabilities belong in existing acceptance outcomes unless independently valuable Features are evidenced. Epic approval never approves child Features.
+
+## Review artifact, not duplicate reader sections
+
+Keep the assessment in a governed review artifact linked from the canonical Epic record, not a second mutable completeness table or Canonical product questions section on the concise Epic reader. Record the canonical Scope revision and a journey-to-Feature coverage table:
+
+| User journey outcome | Canonical Feature link | Coverage or gap |
+|---|---|---|
+| `<OUTCOME>` | `<RESOLVED-RECORD-URL>` | `<EVIDENCE-BOUNDED ASSESSMENT>` |
+
+State shared acceptance expectations, excluded outcomes, any supported new Feature proposal, and the exact human decision needed. Link the Epic-owned canonical Question records; do not introduce a global question register or duplicate question bodies. Conditional approval must retain exact unresolved questions or equivalent conditions as Architecture risks.
+
+## Validation and publication
+
+Test the review's outcome coverage, canonical links, preserved exclusions and proposal label. Test that the Epic reader retains its mandated card and Questions/Features groups without duplicate review sections. Run targeted checks, the required full validation/build and review workflow; never manufacture a Feature to satisfy cadence. Reuse the existing authoritative Scope review when applicable, verify exact-head CI and remote readback, and re-read only approved channels for late substantive decisions.

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.

tests/test_contracts.py

@@ -0,0 +1,42 @@
+"""Offline regression tests for normative skill-package contracts, not runtime behavior."""
+from pathlib import Path
+import re
+import unittest
+ROOT = Path(__file__).resolve().parents[1]
+SKILL = (ROOT / 'SKILL.md').read_text()
+def ref(name):
+    return (ROOT / 'references' / name).read_text()
+class Contracts(unittest.TestCase):
+    def test_evidence_and_links(self):
+        self.assertIn('(references/aerosim-lessons-review.md)', SKILL)
+        evidence = ref('aerosim-lessons-review.md')
+        self.assertRegex(evidence, r'Source commit: `[0-9a-f]{40}`')
+        self.assertIn('## Exclusions', evidence)
+        for path in re.findall(r'\]\((references/[^)#]+)(?:#[^)]*)?\)', SKILL):
+            self.assertTrue((ROOT / path).is_file(), path)
+    def test_capture_is_not_acceptance(self):
+        block = SKILL.split('### Acceptance-gap discovery')[1].split('## Handoffs')[0]
+        for term in ['not retroactive approval', 'missing evidence does not prove', 'immutable Scope revision', 'distinct tested application revision', 'one row per outcome', 'Re-evaluate completeness', 'Never transfer runtime observations', 'do not grant acceptance']:
+            self.assertIn(term, block)
+    def test_review_identity_and_content_readback(self):
+        for term in ['complete candidate diff', 'untracked candidate files', 'claim ledger', 'changed base', 'HTTP 200 is not content verification', 'self-review is not a substitute for independent review']:
+            self.assertIn(term, SKILL)
+    def test_reader_contract_consistency(self):
+        self.assertIn('delivery status | Status basis |', SKILL)
+        self.assertNotIn('delivery status | EXACT/DERIVED |', SKILL)
+        review = ref('feature-set-completeness.md')
+        self.assertIn('governed review artifact', review)
+        self.assertNotIn('## Epic-page pattern', review)
+        self.assertNotIn('## Canonical product questions', review)
+    def test_review_precedes_push(self):
+        workflow = SKILL.split('## Synchronization Workflow')[1].split('## Authority')[0]
+        self.assertLess(workflow.index('required pre-publication review'), workflow.index('Push the smallest'))
+
+    def test_eight_channel_boundary(self):
+        boundary = SKILL.split('## Approved Information Boundary')[1].split('## ', 1)[0]
+        channels = re.findall(r'^<code>-(.+)$', boundary, re.M)
+        self.assertEqual(channels, ['general', 'scope', 'architecture', 'ui-ux', 'kanban', 'delivery', 'uat', 'releases'])
+        self.assertIn('1552966246591365123', boundary)
+
+if __name__ == '__main__':
+    unittest.main()