feat: define Scope documentation structure

SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: corp-v1-channel-general
 description: "Use when operating or synchronizing a Corp v1 project's general channel. Correlates verified activity across the project's general, architecture, delivery, and releases channels; reports overall status, surfaces issues, proposes improvements, and maintains current project-level guidance."
-version: 1.1.0
+version: 1.2.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -74,7 +74,14 @@ Stay silent when nothing substantive changed.
 
 Identify opportunities grounded in project messages, requirements, architecture, delivery evidence, user feedback, or release outcomes. Hermes is an active participant in discovery: on every synchronization iteration, add or materially improve at least one useful project artifact when safe and evidence permits. Prefer refining an existing item over creating noise or duplicates.
 
-All Epics and Features must live in the project documentation repository, not only in Discord. Maintain a durable product registry with stable IDs such as `EPIC-0001` and `FEAT-0001`, links between Features and parent Epics, and preserved status history.
+All Epics, Features, and Ideas must live in the project documentation repository, not only in Discord. Use the uppercase project code in stable identifiers:
+
+```text
+Epic:    <UPPERCASE_PROJECT_CODE>-EP-<NUMBER>
+Feature: <UPPERCASE_PROJECT_CODE>-FT-<NUMBER>
+```
+
+For project code `xyz`, examples are `XYZ-EP-1`, `XYZ-EP-2`, `XYZ-FT-1`, and `XYZ-FT-2`. Allocate each type's next number monotonically. Never reuse an ID after rejection, deferral, deletion, or consolidation, and never renumber existing records merely to close a gap.
 
 Minimum fields:
 
@@ -97,7 +104,51 @@ Use lifecycle states `Proposed`, `Approved for Solution`, `Rejected`, or `Deferr
 
 ## Project Documentation Ownership
 
-The project documentation repository is authoritative for Epics, Features, overall project status, issues, and durable general-channel decisions. Discord announces and discusses changes; it does not replace documentation.
+The project documentation repository is authoritative for Roadmap, Epics, Features, Ideas, overall project status, issues, and durable general-channel decisions. Discord announces and discusses changes; it does not replace documentation.
+
+### Mandatory Scope information architecture
+
+Every project documentation site must expose **Scope** as a top-level navigation item immediately **before Architecture**. Scope must be a dedicated documentation area with its own sidebar—not a category inside another area's sidebar.
+
+The Scope sidebar order and hierarchy are mandatory:
+
+```text
+Roadmap
+Epics
+  <CODE>-EP-1
+    <CODE>-FT-1
+    <CODE>-FT-2
+  <CODE>-EP-2
+    ...
+Ideas
+```
+
+The pages and navigation must satisfy this contract:
+
+1. **Roadmap** always reflects both the verified current situation and the predicted upcoming plan at Epic and Feature level. Distinguish actual/approved state from forecasts and proposals; include status, sequence or horizon, dependencies, material blockers, and last evidence/update date. Refresh it whenever an Epic or Feature changes materially.
+2. **Epics** is the ordered registry and hierarchy for all Epic records. Each Epic has its own page titled with its stable `<CODE>-EP-N` ID and human-readable title.
+3. Each **Epic page** contains at least the Epic title, description, and a Features section with a table linking every child Feature and showing its current status. The table must not contain unlinked or nonexistent Feature IDs.
+4. Each **Feature** is nested under its parent Epic in the sidebar and has its own page titled with its stable `<CODE>-FT-N` ID and human-readable title.
+5. Each **Feature page** contains at least the Feature title, description, and a Tasks section with a table linking every architecture-owned implementation task and showing its current status. Preserve the task identifiers established by the Architecture channel; do not create duplicate General-channel task records.
+6. **Ideas** tracks early opportunities that are not yet accepted as Epics or Features. Each Idea records a stable local reference, title, description, evidence/source, owner when known, status, and any resulting Epic/Feature link. Promotion preserves provenance rather than deleting the Idea.
+
+Minimum Epic Features table:
+
+```markdown
+| Feature | Title | Status |
+|---|---|---|
+| [XYZ-FT-1](./xyz-ft-1) | Example feature | Proposed |
+```
+
+Minimum Feature Tasks table:
+
+```markdown
+| Task | Title | Status |
+|---|---|---|
+| [authoritative task ID](task-record-link) | Example task | Planned |
+```
+
+Validate top-menu order, Scope's dedicated sidebar, hierarchy, unique IDs, parent-child relationships, and every Epic→Feature and Feature→Task link during documentation builds. Empty registries require useful empty-state pages; they do not justify omitting Scope, Roadmap, Epics, or Ideas.
 
 Each useful iteration must add or materially improve at least one evidence-based artifact—for example a grounded proposal, better value/scope/acceptance outcomes, deduplication, status from an explicit human decision, cross-links, or a concrete unanswered product question. Never create filler merely to satisfy cadence. If evidence is insufficient, document and raise the specific blocker/question.
 
@@ -134,11 +185,12 @@ Changes to governance, authority boundaries, destructive operations, secrets, co
 2. Read new messages from the other three channels and enough `general` history to avoid duplicates.
 3. Separate facts, approved decisions, proposals, unresolved questions, and failed work.
 4. Correlate impact across architecture, delivery, and releases.
-5. Inspect the project documentation's Epic/Feature and status registries.
+5. Inspect Scope navigation, Roadmap, Epics, Features, Ideas, task links, and lifecycle status.
-6. Add or materially improve at least one useful evidence-based documentation artifact; never create filler solely to satisfy cadence.
+6. Reconcile the Roadmap whenever current or predicted Epic/Feature state changed.
-7. Perform other safe, reversible coordination work when useful.
+7. Add or materially improve at least one useful evidence-based documentation artifact; never create filler solely to satisfy cadence.
-8. Verify every performed action through checks and remote readback.
+8. Perform other safe, reversible coordination work when useful.
-9. Post one concise update with documentation path and commit evidence, or state the concrete blocker that prevented a useful change.
+9. Validate Scope menu order, dedicated sidebar hierarchy, identifiers, relationships, links, and the documentation build; verify changes through remote readback.
+10. Post one concise update with documentation path and commit evidence, or state the concrete blocker that prevented a useful change.
 
 ## Authority and Escalation
 
@@ -171,6 +223,10 @@ For completed work include exact evidence such as Discord message IDs, repositor
 5. Rewriting the skill from unapproved chat opinions.
 6. Correlating channels from another project.
 7. Claiming work completed without readback evidence.
+8. Placing Scope after Architecture or embedding it in another area's sidebar.
+9. Using generic `EPIC-0001`/`FEAT-0001` IDs instead of project-scoped `<CODE>-EP-N`/`<CODE>-FT-N` IDs.
+10. Letting the Roadmap become a static wish list that does not distinguish current evidence from predicted plans.
+11. Listing Features or Tasks without links, current statuses, or valid parent relationships.
 
 ## Verification Checklist
 
@@ -178,7 +234,12 @@ For completed work include exact evidence such as Discord message IDs, repositor
 - [ ] The update is new, substantive, and deduplicated.
 - [ ] Overall status, issues, and cross-channel implications are accurate.
 - [ ] Proposals are clearly labeled and routed.
-- [ ] Epics and Features are persisted in project documentation with stable IDs and lifecycle state.
+- [ ] Scope appears immediately before Architecture in the top menu and uses its own sidebar.
+- [ ] Scope sidebar order is Roadmap, Epics with nested Features, then Ideas.
+- [ ] Roadmap shows current evidence and predicted Epic/Feature plans distinctly and is current.
+- [ ] Epics and Features use stable `<CODE>-EP-N` and `<CODE>-FT-N` IDs and lifecycle state.
+- [ ] Every Epic links all child Features with statuses; every Feature links all authoritative tasks with statuses.
+- [ ] Ideas and their promotion provenance are maintained.
 - [ ] At least one useful artifact was added or materially improved, or a concrete evidence blocker was raised.
 - [ ] No Epic or Feature was marked `Approved for Solution` without an explicit human team-member decision.
 - [ ] Guidance changes derive from verified team decisions.