corp-v1/portal
2
0
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity

docs: explain Corp v1 SDLC and rebuild diagrams
Build and publish Corp v1 Board portal / build (pull_request) Successful in 36s
Details

Browse Source
This commit is contained in:
jarvis-at-skic
2026-08-25 19:45:33 +00:00
parent 1881254315
commit 17e09ee8ec
9 changed files with 165 additions and 186 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture-high-level/overview.mdx
+20 -14
View File
@@ -1,7 +1,7 @@
---
id: overview
title: "Overview"
description: "Follow a Corp v1 project from Board approval through governed scope, delivery, deployment, and verified evidence."
description: "Follow the single-agent, multi-session Corp v1 pilot from Board governance through design, delivery, release, and verified evidence."
---
import Drawio from '@theme/Drawio';
@@ -9,22 +9,28 @@ import overviewDiagram from '!!raw-loader!./diagrams/overview.drawio';
# Overview
Every approved Corp v1 project repeats the same high-level operating flow while keeping its own decisions and delivery boundary.
Corp v1 is an SDLC operating-model pilot: **one AI agent works across multiple focused Discord sessions, each governed by specialised project skills and explicit human decision rights**. Every approved project repeats the same flow while keeping its decisions, repositories, and delivery evidence isolated.
<Drawio content={overviewDiagram} title="Corp v1 project operating flow" toolbar="zoom layers lightbox" responsive maxHeight={720} />
<Drawio content={overviewDiagram} title="Corp v1 governed project operating flow" toolbar="zoom layers lightbox" responsive maxHeight={820} />
## How projects operate
## How the setup fits together
1. **Board approval** establishes the project purpose, code, lead, members, visibility, initial deliverable, and required resources.
2. **Scope** turns evidence-backed intent into Ideas, Epics, and Features. A human project member approves a Feature for solution work.
3. **Architecture** defines requirements, decisions, diagrams, and implementation Tasks without treating documentation scaffolding as an approved target design.
4. **Kanban** exposes unfinished work. A human project member explicitly admits an exact Task to Focus before Delivery may execute it.
5. **Delivery** implements through reviewable branches and pull requests; Gitea Actions validates the exact candidate.
6. **Releases** assess immutable artifacts, risk, rollback, deployment, and acceptance evidence.
7. **Verification** reads the deployed page or runtime back and updates durable project and governance records.
1. **`corp-v1-board` governs the portfolio.** Listed Board members approve project kickoffs, closures, membership changes, and changes to the global operating model.
2. **General establishes the project workspace.** It handles onboarding, shared coordination, questions, and broadcasts verified outcomes.
3. **Scope decides what creates value.** Ideas become Epics and Features; a human project member approves an exact Feature for solution work.
4. **Architecture decides how the system should work.** Requirements, ADRs, interfaces, constraints, and implementation Tasks become durable project evidence.
5. **UI/UX makes the frontend experience implementable.** User journeys, information architecture, accessibility, Penpot designs, prototypes, and handoff evidence bridge Architecture and execution.
6. **Kanban controls admission and flow.** A human project member admits an exact Task to Focus before Delivery may execute it.
7. **Delivery produces a reviewed candidate.** Work proceeds through branches, pull requests, exact-head validation, and reviewable implementation evidence.
8. **Releases control deployment and outcomes.** Immutable artifacts, risk, rollback, deployment, acceptance, and post-release evidence are assessed explicitly.
9. **Verification closes the evidence loop.** Hermes reads the deployed page or runtime back, updates project documentation and the Board portal, and reports remaining gates honestly.
## Project-owned operating guidance
## Why sessions and skills are separated
Each project adopts six channel skills and seven engineering skills into its dedicated skills/code-agent organization. Those copies preserve project naming, environment namespaces, repository links, authority decisions, and operating lessons. Central changes are compared and deliberately synchronized; they never silently overwrite project decisions.
Each channel is a concern boundary with its own session. The same agent can coordinate the whole project, while the loaded project-adopted channel skill prevents responsibilities and approval rules from blurring together. The project uses seven channel skills to define the workspaces and seven engineering skills to provide reusable execution practices.
Corp v1 projects and channels do **not** use cronjobs or scheduler jobs under the current approved model. Coordination is human- or event-driven.
Project copies preserve project-specific authority, terminology, repository links, environment namespaces, and operating lessons. Central skill changes are compared and deliberately adopted; they never silently overwrite project decisions.
## Automation boundary
Corp v1 projects and channels do **not** use cronjobs or scheduler jobs under the current approved model. Work advances through explicit human decisions, Discord events, reviewed repository changes, exact-commit CI, and deployed readback.