---
title: "Onboarding"
description: "Join the Corp v1 pilot with the right access, context, channel routing, authority, security practices, and evidence expectations."
sidebar_position: 1
---

# Onboarding

Use this page when joining the Corp v1 pilot or entering a project for the first time. You should finish with the right access, a clear role, and enough context to contribute without bypassing project governance.

## What the pilot is

Corp v1 tests whether one AI agent can support several focused project workstreams while people retain explicit authority and durable oversight. The pilot currently includes:

- [AeroSim](/projects/aerosim/)
- [Maze Next Gen](/projects/mazeng/)
- [E-Shop v1](/projects/eshopv1/)

The [Board](/board/) governs project kickoff, closure, and changes to the main Corp v1 operating model. Each project has its own sponsor, team, approved scope, repositories, documentation, Discord category, and preserved authority decisions.

## Your first 20 minutes

1. **Confirm your identity and role.** Check the [member registry](/members/) and your [team record](/teams/). If either is wrong, raise it before taking ownership of work.
2. **Open the project record.** Read its purpose, initial deliverable, current status, resources, and outstanding gates in the [project registry](/projects/).
3. **Open the project documentation.** It is the durable source for scope, architecture, design, Kanban state, ways of working, engineering guidance, and release evidence.
4. **Verify Discord access.** Every project has one dedicated `corp-v1-<code>` category with seven lifecycle channels. Confirm that you can see the channels needed for your role and read their pinned guidance.
5. **Verify Gitea access.** Confirm access to the project and skills organizations through the appropriate teams. Do not request direct repository access when team membership is the intended route.
6. **Choose one current outcome.** Start from an existing Epic, Feature, task, issue, design package, or release gate. Do not create parallel records because an item is difficult to find.

## Use the seven channels correctly

Work moves through this shared lifecycle:

```text
General → Scope → Architecture → UI/UX → Kanban → Delivery → Releases
```

| Channel | Use it for |
|---|---|
| **General** | Project-wide direction, coordination, questions, outcomes, and cross-channel issues |
| **Scope** | Ideas, Epics, Features, value, acceptance outcomes, and product decisions |
| **Architecture** | Solution design, interfaces, constraints, risks, and implementation task definitions |
| **UI/UX** | User journeys, Penpot designs, responsive behavior, accessibility, and implementation handoff |
| **Kanban** | Flow visibility, task admission, sequencing, dependencies, and blockers |
| **Delivery** | Implementation, tests, reviews, CI, build health, and delivery evidence |
| **Releases** | Version readiness, changelogs, deployment approval, rollout, rollback, and runtime verification |

Post in the channel that owns the decision or artifact. Cross-link evidence instead of copying whole conversations between channels. Keep one project’s information inside that project’s seven-channel boundary unless a Board-level concern requires escalation.

## Understand authority

- **Board authority** covers project kickoff, project closure, and changes to `corp-v1-main`.
- **Project-team authority** covers decisions inside the project’s approved boundary.
- **Hermes authority** is project-specific. It may range from preparing proposals to full delegated delivery and merge authority. Use the preserved project record and channel skill; never infer authority from activity, silence, CI success, or an agent statement.
- **Explicit gates remain explicit.** A decision must identify the item, actor, conditions, and evidence. Delegation changes who may decide; it does not remove security, quality, traceability, or validation gates.

When authority is unclear, stop at a reversible proposal and ask in the owning channel.

## Know what “done” means

Keep these states separate:

1. **Approved** — an authorized person or delegate accepted the exact scope or decision.
2. **Implemented** — source changes exist and passed the required local/review checks.
3. **Merged** — the reviewed change is integrated into the repository’s default branch.
4. **Deployed / runtime verified** — the intended immutable revision is running and has passed live readback or acceptance checks.
5. **Released / accepted** — the project’s release authority approved the version and required outcomes.

Always state the highest level actually proven and link the evidence. Do not use “live” as a shortcut for release approval or product maturity.

## Security and credentials

- Never paste passwords, tokens, API keys, connection strings, secret values, or Bitwarden object metadata into Discord, issues, repositories, prompts, screenshots, or documentation.
- Use the approved SSO and secret-injection paths. A credential being available does not authorize unrelated access, account administration, spending, or destructive work.
- Record secret **names and readiness only** when governance requires it.
- Report suspected exposure immediately in the owning project and follow the approved rotation path.
- Treat private project repositories, project-channel history, and customer or operational data as project-bound information.

## How to make a useful contribution

A useful contribution is small enough to review and complete, but durable enough to help the next person:

- start from a stable item or create a clearly marked proposal;
- cite the source message, decision, requirement, design, issue, or runtime observation;
- work in the owning channel and canonical repository;
- preserve project naming, branch, testing, and documentation conventions;
- run the required validation and match CI to the exact commit;
- read back remote and deployed state before claiming completion;
- report the outcome, evidence, remaining gates, owner, and next action concisely.

If a task crosses channels, finish the source-owned result and hand off one clear requested action with evidence and unresolved risks.

## Where truth lives

| Information | Authoritative location |
|---|---|
| Portfolio governance, Board decisions, teams, and project registry | This Corp v1 portal |
| Product scope and project delivery records | Project documentation repository and deployed documentation |
| Source, reviews, commits, CI, and releases | Project Gitea repositories |
| Discussion, approvals, coordination, and handoffs | Exact project Discord channels and message IDs |
| Deployment and runtime state | GitOps source, Argo CD, workload state, and live acceptance evidence |
| Editable interface design | Project-owned Penpot files linked from project records |

No single status message replaces these sources. Reconcile them when they disagree.

## Onboarding complete

You are ready to contribute when you can answer:

- Which project and outcome am I supporting?
- What is my role and decision authority?
- Which channel owns my next action?
- Where is the canonical record?
- What evidence is required before I call it complete?
- Which security or release gates still apply?

If any answer is missing, ask in the project’s **General** channel and link the record you already checked.