docs: define requirements information architecture

SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: corp-v1-channel-architecture
 description: "Use when operating or synchronizing a Corp v1 project's architecture channel. Maintains C4-based architecture documentation, Draw.io diagrams, architecture decisions, and requirements while correlating verified activity across the project's six channels."
-version: 1.4.0
+version: 1.5.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -76,13 +76,16 @@ Use mapped-channel history to avoid duplicate work and new relevant activity fro
 ```text
 Context
 Overview
-Containers
+Container Registry
-Features
+Requirements - Functional
-  <FEATURE-ID>
+  Registry
-    Overview
+  <FR-ID>
+Requirements - Non-Functional
+  Registry
+  <NFR-ID>
 ```
 
-Do not add unrelated first-level items or rename these entries. Architecture decisions, requirements, tasks, dependencies, and version evidence remain authoritative Architecture records but are linked from the applicable Context, Overview, Container, or Feature Overview page rather than expanding the required first-level sidebar.
+Do not add unrelated first-level items or rename these entries. In particular, Architecture has no `Features` menu, Feature reader pages, task registry page, or task reader navigation. Architecture decisions, implementation-task derivation, dependencies, readiness, and version evidence remain authoritative Architecture semantics but are linked from Context, Overview, the applicable Container Registry entry, or FR/NFR pages rather than expanding this sidebar. Scope hosts canonical Epic, Feature, and task reader pages.
 
 ### Context
 
@@ -90,27 +93,25 @@ Do not add unrelated first-level items or rename these entries. Architecture dec
 
 ### Overview
 
-`Overview` is the project-wide component map and maps to C4 **Component**. It summarizes significant logical components, responsibilities, dependencies, interfaces, and links to owning containers and Features. Use one or more editable Draw.io component diagrams; for many containers, provide a readable cross-container overview and link detailed views rather than creating one unreadable canvas.
+`Overview` maps to the C4 **Container** level (C2). It shows the deployable or runnable applications, services, data stores, queues, major technologies, responsibilities, interfaces, and material relationships that make up the project. It must not be an aggregate Component view. Include an editable Draw.io C2 Container diagram and link to the Container Registry for deeper per-container views.
 
-### Containers
+### Container Registry
 
-`Containers` is the C4 **Container** registry and view. It documents deployable/runnable applications, services, data stores, queues, major technologies, responsibilities, interfaces, and relationships. Include an editable Draw.io container diagram and a linked table of containers. Detailed views may be nested in-page without changing the mandatory first-level sidebar.
+`Container Registry` indexes the C2 containers from Overview. It is an information-architecture registry, not another C4 level. Each entry links to a dedicated C3 **Component view** whose subject remains that container. The C3 page opens the selected container to show relevant internals and surrounding relationships.
 
-### Features
+### Requirements - Functional
 
-`Features` contains a table of all Architecture-eligible Features, using stable IDs owned by Scope/General:
+`Requirements - Functional` contains a registry plus one separate reader page per stable `FR-*` requirement. Architecture derives and maintains FRs from approved Scope Features and preserves reciprocal traceability to the exact source Feature, acceptance outcome, related ADR/C4 element, implementation tasks, status, and evidence. The registry is an index, not a substitute for the reader pages.
 
-```text
+### Requirements - Non-Functional
-Feature ID | title | parent Epic | solution status | implementation status | target version | dependencies | Overview link
-```
 
-Each Feature ID is nested under `Features` and contains an `Overview` page. Feature Overview consolidates its approved problem/outcome, FRs/NFRs, affected Context/Containers/Components, ADRs, interfaces/data flows, task/dependency breakdown, risks, target version, implementation approval evidence, and Kanban handoff. Add editable Draw.io diagrams wherever they materially clarify the Feature—normally at least an affected-component, interaction, sequence, data-flow, or deployment-impact view. If no Feature-specific diagram adds value, record why and link the relevant shared Context, Overview, or Containers diagram.
+`Requirements - Non-Functional` contains a registry plus one separate reader page per stable `NFR-*` requirement. Architecture derives and maintains measurable NFRs from approved Scope Features and cross-cutting constraints, preserving reciprocal traceability to exact source Features, acceptance outcomes, related ADR/C4 elements, implementation tasks, verification methods, status, and evidence.
 
-Documentation and diagrams must reflect approved/current truth. Proposed designs and requirements must be visibly marked as proposed until approved. Every registry row and diagram element must link to authoritative records where Docusaurus permits.
+Documentation and diagrams must reflect approved/current truth. Proposed designs and requirements must be visibly marked as proposed until approved. Every registry row and diagram element must link to authoritative records where Docusaurus permits. Do not recreate Scope Feature prose or task reader content inside Architecture.
 
 ## Epic and Feature Transition
 
-For each human-approved Feature from the General documentation registry:
+For each human-approved Feature from canonical Scope:
 
 1. verify its stable ID, parent Epic, scope, value, acceptance outcomes, status, and human approval evidence;
 2. set solution status to `In Solution` without changing product approval history;
@@ -143,7 +144,7 @@ Every diagram must include a title, scope, element names, responsibilities, rela
 4. Onboard the source through `docusaurus-plugin-drawio` using the MDX source-import workflow from `documentation-docusaurus`; do not publish only a static export.
 5. Export an additional review format only when `drawio-main` or project policy requires it.
 6. Validate Draw.io source, Docusaurus build, source import, selected page/pageId, browser rendering, and console/network output.
-7. Link diagrams from Context, Overview, Containers, and Feature Overview pages as applicable.
+7. Link diagrams from Context, Overview, Container Registry entries, and FR/NFR pages as applicable.
 8. Commit source, MDX/configuration, lockfile, and any required rendered output together.
 9. Record exact paths and commit evidence.
 
@@ -167,7 +168,7 @@ A scheduled run may draft an ADR from verified context, but may not mark it Acce
 
 ## Requirements Registries
 
-Maintain separate functional and non-functional registries.
+Maintain separate functional and non-functional registries and one separate reader page for every requirement. Derive both classes from canonical Scope Features while keeping Architecture as the requirement owner.
 
 Functional requirement minimum fields:
 
@@ -181,17 +182,17 @@ Non-functional requirement minimum fields:
 ID | quality attribute/constraint | measurable target | scope | status | verification method | related ADR/C4 element
 ```
 
-Use stable IDs such as `FR-0001` and `NFR-0001`. Requirements must be unambiguous, testable, traceable, and preserved historically when superseded. Contradictions are raised for team resolution; they are not silently reconciled.
+Use stable IDs such as `FR-0001` and `NFR-0001`. Requirements must be unambiguous, testable, traceable to exact Scope Features and acceptance outcomes, and preserved historically when superseded. Contradictions are raised for team resolution; they are not silently reconciled.
 
 ## Task and Dependency Breakdown
 
-Maintain a task registry in project documentation:
+Architecture derives and maintains implementation-task semantics, dependencies, sequencing, and readiness from the FR/NFR solution. Scope hosts the canonical task records and reader pages under their owning Feature; Architecture must not create a competing task registry page or task navigation.
 
 ```text
-ID | feature | outcome | scope | dependencies | owner | status | acceptance evidence | affected repository/component
+canonical_id | display_id | feature | outcome | scope | dependencies | owner | status | acceptance evidence | affected repository/component
 ```
 
-Use stable IDs such as `TASK-0001`. Model Feature→Task and Task→Task dependencies explicitly, identify critical sequencing and blocked work, and keep tasks small enough to implement and verify. Tasks may be drafted proactively, but only tasks belonging to a human-approved `Approved for Implementation` Feature may be proposed to Kanban. A human team member must separately approve each ready task into Focus `InBacklog` before Delivery execution.
+Use canonical Task IDs `TASK-<ZERO_PADDED_NUMBER>` and separate project-scoped display IDs `<UPPERCASE_PROJECT_CODE>-TS-<NUMBER>`. Both fields are mandatory for every Task. Bind dependencies, links, event histories, evidence, and append-only hashes to `canonical_id`; use `display_id` only for reader-facing navigation and labels. Never infer or rewrite canonical identity from a display ID. Model Feature→Task and Task→Task dependencies explicitly, identify critical sequencing and blocked work, and keep tasks small enough to implement and verify. During migration, preserve historic canonical identities, aliases, event evidence, and append-only hashes; do not rewrite prior records or hashes solely to adopt the display convention. Tasks may be drafted proactively, but only tasks belonging to a human-approved `Approved for Implementation` Feature may be proposed to Kanban. Focus admission requires a separate human decision.
 
 ## Version Allocation
 
@@ -210,10 +211,10 @@ Every architecture iteration must add or materially improve a useful project-doc
 1. Read new same-project activity and enough architecture history to avoid duplicates.
 2. Inspect documented Epics/Features and verify human `Approved for Solution` evidence before selecting work.
 3. Identify changed assumptions, requirements, interfaces, constraints, infrastructure, deployment topology, or runtime behavior.
-4. Compare evidence with C4 views, ADRs, requirement, task/dependency, and version registries.
+4. Compare evidence with the required Architecture information architecture, C4 views, ADRs, FR/NFR registries and pages, Scope-hosted task records, dependencies, readiness, and version evidence.
 5. Add or materially improve at least one useful solution artifact for an eligible Feature.
 6. Use `drawio-main` for every diagram change and `documentation-docusaurus` for every documentation, navigation, MDX, plugin, or embedding change.
-7. Validate the exact Architecture sidebar, Features hierarchy/table, links, Draw.io source embedding, Docusaurus build, and browser rendering; then perform remote readback.
+7. Validate the exact Architecture sidebar, FR/NFR registries and reader pages, absence of Architecture Feature/task navigation, reciprocal Scope traceability, links, Draw.io source embedding, Docusaurus build, and browser rendering; then perform remote readback.
 8. Post a concise update with changed artifacts, implications, unresolved decisions, approval gate, and exact evidence.
 
 ## Authority and Escalation
@@ -250,9 +251,11 @@ Requires team approval for:
 9. Starting solution work for a Feature without explicit human approval.
 10. Moving a Feature into implementation or assigning a final version based on Hermes's own judgment.
 11. Creating task lists without explicit dependencies and traceability.
-12. Adding first-level Architecture sidebar items outside Context, Overview, Containers, and Features.
+12. Adding first-level Architecture sidebar items outside Context, Overview, Container Registry, Requirements - Functional, and Requirements - Non-Functional.
-13. Treating Overview as System Context instead of the project-wide C4 Component map.
+13. Treating Overview as a Component map instead of the project-wide C2 Container view.
 14. Publishing static diagram exports without onboarding the editable `.drawio` source into Docusaurus.
+15. Reintroducing Architecture Feature pages or task reader navigation instead of linking canonical Scope pages.
+16. Renaming task display IDs by rewriting historic canonical identities, evidence, or append-only hashes.
 
 ## Verification Checklist
 
@@ -261,14 +264,16 @@ Requires team approval for:
 - [ ] C4 scope and level are appropriate.
 - [ ] `drawio-main` governed every diagram change.
 - [ ] `documentation-docusaurus` governed navigation, MDX, plugin, and source embedding changes.
-- [ ] Architecture has its dedicated sidebar ordered Context, Overview, Containers, Features → Feature ID → Overview.
+- [ ] Architecture has its dedicated sidebar ordered Context, Overview, Container Registry, Requirements - Functional → Registry + FR pages, Requirements - Non-Functional → Registry + NFR pages.
-- [ ] Context maps to C4 System Context, Overview maps to C4 Component, and Containers maps to C4 Container.
+- [ ] Architecture has no Features menu/pages and no task registry/reader navigation.
-- [ ] Features table and every Feature Overview use stable linked IDs and current approval/version/dependency evidence.
+- [ ] Context maps to C4 System Context; Overview maps to C2 Container; Container Registry entries open per-container C3 Component views.
+- [ ] Every FR/NFR has its own reader page and reciprocal traceability to exact canonical Scope Features and acceptance outcomes.
 - [ ] Draw.io diagrams exist wherever materially useful; any omission is justified and links to the applicable shared diagram.
 - [ ] Editable `.drawio` sources render through Docusaurus and pass build plus browser verification.
 - [ ] ADR, FR, and NFR entries have stable IDs and traceability.
 - [ ] Every solution Feature has explicit human `Approved for Solution` evidence.
-- [ ] Eligible Features have dependency-aware task breakdowns and version proposals.
+- [ ] Eligible Features have dependency-aware task derivation and version proposals, with canonical task reader pages under their Scope Feature.
+- [ ] Task display IDs use `<UPPERCASE_PROJECT_CODE>-TS-<NUMBER>` without rewriting historic canonical identities, evidence, or append-only hashes.
 - [ ] Only a human team member moved a Feature to `Approved for Implementation` or finalized its version.
 - [ ] Tasks were proposed to Kanban with readiness/dependency evidence; Architecture did not self-admit them to Focus `InBacklog`.
 - [ ] At least one useful solution artifact was improved, or the exact human approval/clarification gate was documented.