7.2 KiB
title, description, sidebar_position
| title | description | sidebar_position |
|---|---|---|
| Onboarding | Join the Corp v1 pilot with the right access, context, channel routing, authority, security practices, and evidence expectations. | 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:
The 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
- Confirm your identity and role. Check the member registry and your team record. If either is wrong, raise it before taking ownership of work.
- Open the project record. Read its purpose, initial deliverable, current status, resources, and outstanding gates in the project registry.
- Open the project documentation. It is the durable source for scope, architecture, design, Kanban state, ways of working, engineering guidance, and release evidence.
- 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. - 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.
- 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:
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:
- Approved — an authorized person or delegate accepted the exact scope or decision.
- Implemented — source changes exist and passed the required local/review checks.
- Merged — the reviewed change is integrated into the repository’s default branch.
- Deployed / runtime verified — the intended immutable revision is running and has passed live readback or acceptance checks.
- 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.