jarvis-at-skic
6c9b399043
Build and publish Corp v1 Board portal / build (pull_request) Successful in 34s
38 lines
3.3 KiB
Plaintext
38 lines
3.3 KiB
Plaintext
---
|
|
id: operating-model
|
|
title: "Operating Model"
|
|
description: "Follow Corp v1 from Board governance and Guild improvement through project delivery and verified evidence."
|
|
---
|
|
|
|
import Drawio from '@theme/Drawio';
|
|
import operatingModelDiagram from '!!raw-loader!./diagrams/operating-model.drawio';
|
|
|
|
# Operating Model
|
|
|
|
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={operatingModelDiagram} title="Corp v1 governed project operating flow" toolbar="zoom layers lightbox" responsive maxHeight={820} />
|
|
|
|
## How the setup fits together
|
|
|
|
1. **`corp-v1-board` governs the portfolio.** Listed Board members approve project kickoffs, closures, membership changes, and changes to the global operating model.
|
|
2. **`corp-v1-guild` improves the operating system.** RootAtSkic and Hermes identify recurring cross-channel friction, inventory affected skills and repositories, route decisions to their owners, and verify coordinated rollout without replacing Board or project authority.
|
|
3. **General establishes the project workspace.** It handles onboarding, shared coordination, questions, and broadcasts verified outcomes.
|
|
4. **Scope decides what creates value.** Ideas become Epics and Features; a human project member approves an exact Feature for solution work.
|
|
5. **Architecture decides how the system should work.** Requirements, ADRs, interfaces, constraints, and implementation Tasks become durable project evidence.
|
|
6. **UI/UX makes the frontend experience implementable.** User journeys, information architecture, accessibility, Penpot designs, prototypes, and handoff evidence bridge Architecture and execution.
|
|
7. **Kanban controls admission and flow.** A human project member admits an exact Task to Focus before Delivery may execute it.
|
|
8. **Delivery produces a reviewed candidate.** Work proceeds through branches, pull requests, exact-head validation, and reviewable implementation evidence.
|
|
9. **Releases control deployment and outcomes.** Immutable artifacts, risk, rollback, deployment, acceptance, and post-release evidence are assessed explicitly.
|
|
10. **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.
|
|
|
|
## Why sessions and skills are separated
|
|
|
|
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.
|
|
|
|
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.
|