[verified] docs: define Scope task reader hierarchy

SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: corp-v1-channel-scope
 description: "Use when operating or synchronizing a Corp v1 project's Scope channel. Owns Roadmap, Epics, Features, and Ideas; correlates all six same-project channels; proactively improves evidence-based product scope; and records human approval before work enters Architecture solution design."
-version: 1.3.4
+version: 1.4.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -16,7 +16,7 @@ metadata:
 
 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.
 
-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.
+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.
 
@@ -26,7 +26,7 @@ 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;
@@ -70,12 +70,18 @@ Questions
   ...
 Epics
   <CODE>-EP-1
-    <CODE>-FT-1
-    <CODE>-FT-2
+    Features
+      <CODE>-FT-1
+        Tasks
+          <CODE>-TS-1
+          ...
+      <CODE>-FT-2
   <CODE>-EP-2
     ...
 ```
 
+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.
+
 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
@@ -98,16 +104,18 @@ Fail validation when any canonical item is absent or duplicated; a required rela
 
 Any canonical status, relationship, gate, owner, blocker, or evidence change must update Overview in the same reviewed change. Acceptance requires selector/table count parity, type/status total parity, link validation, keyboard and screen-reader access, strict production build, browser console/network health, and remote exact-head readback.
 
-### Epics and Features
+### Epics, Features, and Tasks
 
-Use stable project-scoped IDs:
+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:
 
@@ -121,7 +129,9 @@ Minimum Feature fields:
 ID | Epic | user/problem statement | expected value | scope | acceptance outcomes | status | owner | dependencies | risks | evidence
 ```
 
-Each Epic page uses a concise reader card showing the unified delivery status, owner, goal, benefit, problem/opportunity, constraints, clickable child-Feature tags, and original source, followed by linked Feature/task cards. Do not expose legacy aliases, decision-history tables, a separate Feature-set completeness review, or a Canonical product questions section on the reader page. Each Feature page contains title, description, value, scope, acceptance outcomes, dependencies, risks, human approval evidence, and linked authoritative Architecture tasks when they exist. Scope never creates duplicate task identities.
+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.
 
@@ -133,7 +143,9 @@ Ideas are early opportunities not yet accepted as Epics or Features. Record stab
 
 Questions are governed product decisions, separate from delivery status and approval. Keep a Questions parent page and one sidebar-visible child page per canonical Question. Show the question, why it matters, affected scope, owner, status, answer when available, and original source without using tables.
 
-Render affected or resulting governed records as sharp clickable tags, sorted deterministically by entity type and canonical ID. Every tag resolves the target record's canonical documentation URL; do not emit an unsorted plain list or synthesize a URL from the ID. Label reader-facing source sections **Original source**, not Evidence. For Discord sources, render each link as `Discord – <Channel name> – <Author>` while retaining the exact source-message URL.
+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.
 
@@ -242,7 +254,7 @@ Use evidence from all six same-project channels. Delivery and release outcomes m
 1. Confirm the exact project code and six approved channel IDs.
 2. Read new activity from the other five channels and enough Scope history to avoid duplication.
 3. Separate verified facts, human decisions, proposals, forecasts, and unresolved questions.
-4. Inspect Overview, Roadmap, Epics, Features, Ideas, Questions, links, IDs, unified delivery statuses, required-child roll-ups, and approval evidence.
+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.
 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.
@@ -272,7 +284,7 @@ Requires human approval for:
 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.
@@ -283,17 +295,21 @@ Requires human approval for:
 13. Deriving a parent from an incomplete, duplicated, or unvalidated child set.
 14. Counting a cancelled child as done or silently excluding it without an explicit scope decision.
 15. Moving a parent to `TO_BE_RELEASED` while any required child remains in backlog, design, active delivery, or progress.
+16. Flattening the reader hierarchy by placing Features directly under an Epic or Tasks outside their owning Feature's `Tasks` group.
+17. Rewriting historic canonical identities, evidence, or append-only hashes solely to adopt `<UPPERCASE_PROJECT_CODE>-TS-<NUMBER>` display IDs.
 
 ## Verification Checklist
 
 - [ ] Only the six 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 Epics with nested Features.
+- [ ] Sidebar order is Overview, Roadmap, Ideas with child pages, Questions with child pages, then the exact Epics → Epic → Features → Feature → Tasks hierarchy.
 - [ ] Ways of Working starts with a separate Scope page explaining the ticket hierarchy and governed statuses.
 - [ ] Ideas and Questions use table-free parent/child pages; no Product Register page exists.
 - [ ] Roadmap distinguishes verified current state from predicted plans.
-- [ ] Epics and Features use stable project-scoped IDs and valid parent-child links.
-- [ ] Every Epic links child Features; every Feature links authoritative tasks when present.
+- [ ] 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.
+- [ ] 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.