Build and publish Corp v1 Board portal / build (pull_request) Successful in 34s
63 lines
4.9 KiB
Plaintext
63 lines
4.9 KiB
Plaintext
---
|
|
id: overview-channels
|
|
title: "Overview Channels"
|
|
description: "Understand the Corp v1 Board and Guild channels, seven project workspaces, session boundaries, skills, and SDLC handoffs."
|
|
---
|
|
|
|
import Drawio from '@theme/Drawio';
|
|
import channelsDiagram from '!!raw-loader!./diagrams/channels.drawio';
|
|
|
|
# Overview Channels
|
|
|
|
Corp v1 uses **two central portfolio workspaces** and **seven purpose-specific channels per project**. The central Board and Guild channels serve different purposes; neither is an eighth project channel. All channels are operating boundaries for one AI agent and the human team—not separate delivery teams.
|
|
|
|
<Drawio content={channelsDiagram} title="Corp v1 Board, Guild, and project channel operating model" toolbar="zoom layers lightbox" responsive maxHeight={820} />
|
|
|
|
## Improvement coordination: `corp-v1-guild`
|
|
|
|
`corp-v1-guild` is the shared improvement workspace for RootAtSkic and Hermes. It correlates recurring friction across Corp v1 channels, skills, reference skills, repositories, and this portal; inventories the affected owners; and coordinates a verified rollout.
|
|
|
|
The Guild does not grant approval that belongs to the Board or a project channel. It routes product, architecture, design, flow, implementation, and release decisions back to their owning project workspace. Its authoritative operating skill is [`corp-v1--guild`](https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1--guild).
|
|
|
|
## 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** | 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 |
|
|
|
|
## 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.
|