[verified] docs: govern Questions under owning Epics

Merge central Scope portal-link reporting rule

SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: corp-v1-channel-scope
-description: "Use when operating or synchronizing a Corp v1 project's Scope channel. Owns Roadmap, Epics, Features, and Ideas; correlates all six same-project channels; proactively improves evidence-based product scope; and records human approval before work enters Architecture solution design."
-version: 1.5.1
+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.6.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -14,7 +14,7 @@ metadata:
 
 ## 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.
+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.
 
@@ -22,6 +22,17 @@ Load the global `documentation-docusaurus` skill from `https://gitea.lego-cloud.
 
 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:
@@ -44,12 +55,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
 
@@ -67,11 +79,11 @@ Roadmap
 Ideas
   <CODE>-IDEA-1
   ...
+Epics
+  <CODE>-EP-1
     Questions
       Q-0001
       ...
-Epics
-  <CODE>-EP-1
     Features
       <CODE>-FT-1
         Tasks
@@ -82,7 +94,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.
 
@@ -143,7 +155,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,7 +261,7 @@ 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 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
 
@@ -251,18 +271,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.
-2. Read new activity from the other five channels and enough Scope history to avoid duplication.
+1. Confirm the exact project code and seven approved channel IDs.
+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 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.
+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
 
@@ -303,17 +327,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 seven 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 +355,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.