docs: explain Corp v1 SDLC and rebuild diagrams

docs/architecture-high-level/overview-channels.mdx

@@ -1,7 +1,7 @@
 ---
 id: overview-channels
 title: "Overview Channels"
-description: "Understand how the six Corp v1 project channels divide responsibilities and hand work to one another."
+description: "Understand the Corp v1 Board channel, seven project workspaces, session boundaries, skills, and SDLC handoffs."
 ---
 
 import Drawio from '@theme/Drawio';
@@ -9,17 +9,48 @@ import channelsDiagram from '!!raw-loader!./diagrams/channels.drawio';
 
 # Overview Channels
 
-A project receives exactly six purpose-specific Discord channels. The channels are concern boundaries, not isolated teams: evidence and decisions move forward through explicit handoffs.
+Corp v1 uses **one portfolio-governance channel** and **seven purpose-specific channels per project**. These are operating boundaries for one AI agent and the human team—not separate delivery teams.
 
-<Drawio content={channelsDiagram} title="Corp v1 project channel flow" toolbar="zoom layers lightbox" responsive maxHeight={720} />
+<Drawio content={channelsDiagram} title="Corp v1 Board and project channel operating model" toolbar="zoom layers lightbox" responsive maxHeight={820} />
 
-| Channel | Owns | Typical handoff |
+## Portfolio governance: `corp-v1-board`
+
+`corp-v1-board` exists once for the whole Corp v1 pilot. It is the authoritative Discord workspace for decisions that change the portfolio operating model:
+
+- approve project kickoffs, closures, and membership changes;
+- approve changes to the global `corp-v1--main` governance skill;
+- approve central `corp-v1-channel-*` reference-skill changes;
+- resolve conflicts that cannot be decided inside one project;
+- review portfolio-level evidence and remaining gates.
+
+A Board message is evidence only when approval is explicit and attributable to a listed Board member. The Board channel does **not** replace project Scope, Architecture, UI/UX, Delivery, or Releases decisions.
+
+## Project workspaces
+
+Every active project receives these seven channels in this exact order:
+
+| Channel | Owns | Sends forward |
 |---|---|---|
-| General | Announcements, questions, shared coordination | Routes product intent to Scope and broadcasts outcomes |
-| Scope | Ideas, Epics, Features, value, acceptance outcomes, solution approval | Sends an approved Feature to Architecture |
-| Architecture | Requirements, ADRs, Draw.io views, technical design, implementation Tasks | Sends prepared Tasks to Kanban |
-| Kanban | Board, Focus, flow visibility, explicit human Task admission | Sends admitted work to Delivery |
-| Delivery | Planning, implementation, pull requests, CI evidence, blockers | Sends a validated release candidate to Releases |
-| Releases | Readiness, versions, deployment, rollback, post-release outcomes | Reports deployment state and outcomes to the project |
+| **General** | Project announcements, questions, onboarding, shared coordination, and outcome broadcasts | Product intent and questions to Scope; cross-cutting needs to the owning channel |
+| **Scope** | Ideas, Epics, Features, value, acceptance outcomes, roadmap, and human approval for solution work | An exact approved Feature to Architecture |
+| **Architecture** | Requirements, ADRs, system design, interfaces, constraints, and implementation Tasks | Design intent to UI/UX and prepared technical work toward Kanban |
+| **UI/UX** | User journeys, information architecture, interaction and visual design, accessibility, Penpot sources, prototypes, and design handoff | Reviewed design evidence and implementation-ready UX decisions to Kanban and Delivery |
+| **Kanban** | Board and Focus visibility, dependencies, sequencing, blockers, and explicit human Task admission | An exact admitted Task to Delivery |
+| **Delivery** | Implementation planning, branches, pull requests, reviews, exact-head CI, and engineering blockers | A validated immutable candidate to Releases |
+| **Releases** | Readiness, version decisions, deployment, rollback, acceptance evidence, and post-release outcomes | Verified status and outcomes back to General and durable records |
 
-Each channel loads its mapped project-adopted channel skill. Relevant engineering skills are loaded alongside it for branching, monorepo structure, scripts, CI/CD, GitOps, documentation, and templates. A green build or agent statement never substitutes for a required human approval or deployed readback.
+## One agent, multiple sessions, specialised skills
+
+The same Hermes agent operates across the pilot, but each Discord channel has its own focused session and mapped channel skill. This gives the pilot:
+
+1. **Shared identity and governance** — one agent follows the same Board-approved operating model.
+2. **Focused context** — Scope discussion does not become Delivery execution, and one project's decisions do not silently become another project's decisions.
+3. **Specialised behavior** — the mapped `corp-v1-channel-<channel>--<code>` skill defines the channel's responsibilities, approvals, evidence, and handoffs.
+4. **Engineering depth on demand** — relevant project engineering skills are loaded alongside the channel skill for documentation, branching, monorepo work, CI/CD, GitOps, scripts, and templates.
+5. **Durable evidence** — decisions and current state are written to Discord, Gitea, project documentation, and the Board portal rather than existing only in an agent session.
+
+## Handoff rule
+
+A handoff is not “continue the conversation elsewhere.” It carries an exact governed artifact: an approved Feature, requirement set, ADR, Penpot design, admitted Task, reviewed commit, immutable release candidate, or deployed readback.
+
+Green CI, a merge, an agent statement, or silence never substitutes for required human approval. Corp v1 currently uses no project cronjobs or scheduler jobs; coordination is human- or event-driven.