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

docs: align Corp v1 boundary with owned home-lab containers
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-26 07:52:47 +00:00
parent 73acbd57b3
commit a7951c6130
6 changed files with 111 additions and 89 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture-high-level/context.mdx
+22 -18
View File
@@ -1,7 +1,7 @@
---
id: context
title: "Context"
description: "Identify the Corp v1 target system, the people who use or govern it, and the external collaboration, design, source, and delivery systems around it."
description: "See the Corp v1 home-lab system boundary, its human actors, and its only external systems: the LLM provider and Discord."
---
import Drawio from '@theme/Drawio';
@@ -9,32 +9,36 @@ import contextDiagram from '!!raw-loader!./diagrams/context.drawio';
# Context
The target system on this page is the **Corp v1 Hermes delivery system**: one Hermes Agent operating through focused project sessions, specialised skills, tool integrations, and a durable evidence loop. It helps people govern and deliver projects; it does not replace human authority or become the application being built.
The target system is the **Corp v1 managed delivery platform in Lego's home lab**. The boundary follows operational responsibility: services and managed service slices that Lego deploys, configures, versions, upgrades, secures, or restores are inside the Corp v1 system boundary.
<Drawio content={contextDiagram} title="Corp v1 system context with human actors and external systems" toolbar="zoom layers lightbox" responsive maxHeight={760} />
<Drawio content={contextDiagram} title="Corp v1 home-lab system context" toolbar="zoom layers lightbox" responsive maxHeight={760} />
## Human actors
| Actor | Relationship to the target system |
| Actor | Relationship to Corp v1 |
|---|---|
| **Corp v1 Board members** | Govern the portfolio. They approve project kickoff and closure, membership, the global operating model, and central `corp-v1-channel-*` reference changes. |
| **Project leads and contributors** | Use focused project channels to define value, approve solution work and Task admission, review architecture and UI/UX, implement changes, and accept releases. |
| **Prospective project sponsors and contributors** | May request or join a future Corp v1 project after Board approval, identity resolution, and explicit onboarding. They have no authority merely because they are interested. |
| **Solution users and reviewers** | Supply needs, feedback, usability evidence, and acceptance observations for a project solution. Their product input does not automatically grant Board or project decision rights. |
| **Corp v1 Board members** | Govern the portfolio and approve project lifecycle, membership, the global operating model, and central channel-reference changes. |
| **Project leads and contributors** | Define value, approve solution work and Task admission, review architecture and UI/UX, implement changes, and accept releases. |
| **Prospective project sponsors and contributors** | May request or join future Corp v1 projects after explicit Board approval and onboarding. |
| **Solution users and reviewers** | Provide needs, usability feedback, acceptance observations, and evidence about the products delivered through Corp v1. |
Hermes is an executing system participant, not a human approver. An agent message, CI result, silence, or inferred intent never substitutes for an approval reserved to a listed human actor.
Human authority remains outside automation. Hermes, CI, deployments, inferred intent, and silence never substitute for an approval reserved to a listed person.
## External systems around the target
## External systems
| System | How Corp v1 uses it |
Corp v1 currently has only two external software systems:
| External system | Relationship to Corp v1 |
|---|---|
| **Discord** | Carries Board governance and project channel sessions, human decisions, coordination, and handoff messages. |
| **Penpot** | Holds editable UI/UX design sources and review evidence before implementation. |
| **Gitea and Gitea Actions** | Preserve source, documentation, skills, decisions, pull requests, CI, and GitOps desired state. |
| **LEGO Cloud delivery platform** | Provides Pages, Harbor, Argo CD, the three-node Gondor v1 MicroK8s cluster, ingress, authentication, and deployed readback. |
| **LLM Provider** | Supplies model inference to Hermes Agent. The currently used providers are ICA or GPT Codex. Model execution is consumed as an external capability; Corp v1 does not deploy or maintain the provider platform. |
| **Communication Service — Discord** | Carries Board governance and project conversations. Corp v1 configures and maintains its channel structure, permissions, guidance, and pins, while Discord operates the communication platform itself. |
## Target-system boundary
## Inside the system boundary
Inside the target system are Hermes Agent behavior, focused sessions, skill selection, tool execution, and evidence verification. Human decision rights remain outside that boundary. Discord, Penpot, Gitea, and the delivery platform are connected external systems with their own authority and state.
Hermes Agent and the home-lab services it depends on are internal containers in this architecture: Gitea, Actions runners, Penpot, the Board portal, Pages, Harbor, Argo CD, the access and identity stack, MicroK8s, and the hosted workloads. Their Corp v1 configuration is not modeled as an external dependency because Lego is responsible for its lifecycle and operational state.
A project's product or service is also outside this boundary. Corp v1 can govern its lifecycle and operate its delivery path, but each project must maintain its own product context, requirements, architecture, UI/UX, security, data, and release decisions.
The [Container Overview](/architecture-high-level/overview/) shows those internal containers and their delivery relationships. The [Operating Model](/architecture-high-level/operating-model/) separately explains Board authority, channel sessions, skills, approvals, and handoffs.
## Product boundary
A project product delivered through Corp v1 remains its own product boundary. Corp v1 operates the delivery platform and governs the lifecycle, while every project must maintain its own product context, requirements, architecture, data, security, UI/UX, and release decisions.