corp-v1-channel-scope-3darch/SKILL.md

---
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.1.0
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 Scope Channel

## 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.

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.

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.

## When to Use

Use this skill when:

- operating in `corp-v1-<code>-scope`;
- running its recurring synchronization job;
- maintaining Roadmap, Epics, Features, or Ideas;
- 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;
- reconciling scope against architecture, Kanban, delivery, or release evidence.

Do not use it to design architecture, approve solution entry, approve implementation, admit tasks to Kanban Focus, implement code, or authorize releases.

## Approved Information Boundary

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
```

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.

## Human Approval Gate

Only a human team member may move an Epic or Feature to `Approved for Solution`. Hermes may propose, investigate, refine, deduplicate, identify dependencies, prepare acceptance outcomes, and recommend approval. Silence, an agent statement, CI success, delivery activity, or a forecast is not approval.

Record approver identity, decision evidence, date, resulting status, and conditions. Architecture may begin solution work only after this evidence exists.

## Documentation Contract

`Scope` is a top-level menu item immediately before `Architecture`, with its own dedicated sidebar:

```text
Roadmap
Epics
  <CODE>-EP-1
    <CODE>-FT-1
    <CODE>-FT-2
  <CODE>-EP-2
    ...
Ideas
```

### Roadmap

Show verified current state and predicted plans at Epic and Feature level. Distinguish approved/current facts from forecasts and proposals. Include sequence or horizon, status, dependencies, material blockers, owner, and last evidence/update date.

### Epics and Features

Use stable project-scoped IDs:

```text
Epic:    <UPPERCASE_PROJECT_CODE>-EP-<NUMBER>
Feature: <UPPERCASE_PROJECT_CODE>-FT-<NUMBER>
```

Allocate numbers monotonically. Never reuse or renumber an ID after rejection, deferral, deletion, or consolidation.

Minimum Epic fields:

```text
ID | title | problem/opportunity | intended outcome | value | status | owner | Feature links | evidence
```

Minimum Feature fields:

```text
ID | Epic | user/problem statement | expected value | scope | acceptance outcomes | status | owner | dependencies | risks | evidence
```

Each Epic page contains a linked Features table with current statuses. Each Feature page contains title, description, value, scope, acceptance outcomes, dependencies, risks, human approval evidence, and a linked table of authoritative Architecture tasks when they exist. Scope never creates duplicate task identities.

Lifecycle states are `Proposed`, `Approved for Solution`, `Rejected`, or `Deferred`.

### Ideas

Ideas are early opportunities not yet accepted as Epics or Features. Record stable local reference, title, description, evidence/source, owner when known, status, and resulting Epic/Feature links. Preserve provenance after promotion.

## React Flow visualization contract

When Scope documentation contains relationship-dense data, deliberately consider a read-only `@xyflow/react` view after loading `documentation-docusaurus` and its React Flow guidance. Appropriate Scope views include:

- Epic-to-Feature composition;
- Feature-to-Feature dependencies;
- Feature-to-question readiness relationships;
- Requirement-to-Feature and Architecture-Decision-to-Feature traceability;
- roadmap sequencing and a deterministic Gantt-like timeline when approved dates and lanes exist.

Render a visualization only when the required relationships, dates, lanes, and states exist in validated canonical YAML and the graph materially improves comprehension. A small, linear, empty, or weakly connected dataset should remain a semantic table or list. A graph must not infer unapproved dependencies, dates, hierarchy, readiness, approval, critical path, or progress.

Use one typed, deterministic adapter and the same selector to produce stable nodes, edges, legends, validation warnings, and an adjacent semantic table fallback. Generated graph data, coordinates, viewport state, and client state are derived presentation data, never a second source of truth. Preserve exact relationship semantics: questions, blockers, dependencies, decisions, approval conditions, and readiness are distinct concepts and edge types.

Use Dagre for ordinary directed graphs and ELK only for complex or grouped graphs. Derive Gantt-like positions deterministically from approved dates and lanes. Use Docusaurus `BrowserOnly` where client-only rendering is required, while keeping the semantic fallback server-renderable, searchable, linkable, and usable if JavaScript or hydration fails.

Documentation canvases are read-only. Disable mutation affordances, including `nodesDraggable={false}`, `nodesConnectable={false}`, connection creation, deletion, and accidental persistence. Preserve keyboard navigation, meaningful accessible labels and authoritative-record links, visible focus, non-color-only meaning, reduced-motion behavior, responsive controls, and sharp styling with `border-radius: 0`.

Acceptance requires canonical-YAML validation, graph/table parity from the same selector, stable deterministic output, missing-reference failure or explicit warning behavior, empty/loading/error states, keyboard and screen-reader checks, no-JavaScript fallback, production build, browser console/network health, and remote exact-head verification. React Flow supplements the Roadmap, Epic/Feature records, and semantic tables; it never replaces governed Scope records.

## Proactive Iteration Requirement

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.

## 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 Epic/Feature identities and lifecycle state for Board/Focus reconciliation.
- **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.

## 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.
3. Separate verified facts, human decisions, proposals, forecasts, and unresolved questions.
4. Inspect Roadmap, Epics, Features, Ideas, links, IDs, lifecycle states, 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.
8. Post a concise Scope update with changed artifacts, implications, human gate, and exact evidence. Stay silent when no substantive result exists.

## Authority and Escalation

May autonomously:

- summarize verified same-project scope implications;
- propose and refine Ideas, Epics, and Features;
- maintain Roadmap mechanics, links, IDs, and evidence;
- record explicit human decisions;
- run read-only checks and documentation validation;
- repair clear non-semantic documentation defects.

Requires human approval for:

- moving an Epic or Feature to `Approved for Solution`;
- materially accepting/rejecting product scope;
- changing governance, architecture, implementation, version, or release decisions;
- permissions, credentials, spending, external contact, or irreversible/high-impact work.

## Common Pitfalls

1. Treating General as the authoritative owner of Scope records.
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.
6. Mixing approved/current state with predictions in the Roadmap.
7. Ignoring Architecture, Kanban, Delivery, or Releases evidence.
8. Inspecting another project's channels.
9. Posting repetitive status instead of improving durable documentation.
10. Claiming completion without build and remote readback evidence.

## Verification Checklist

- [ ] Only the six same-project channels were inspected.
- [ ] Scope appears immediately before Architecture with its own sidebar.
- [ ] Sidebar order is Roadmap, Epics with nested Features, then Ideas.
- [ ] 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.
- [ ] Ideas preserve provenance when promoted.
- [ ] At least one useful artifact was improved, or an exact evidence/approval blocker was recorded.
- [ ] 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.
- [ ] 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.