49 lines
3.1 KiB
Markdown
49 lines
3.1 KiB
Markdown
---
|
|
title: "Project Lifecycle"
|
|
description: "Apply the Board-controlled lifecycle for starting, operating, synchronizing, and closing Corp v1 projects."
|
|
slug: /project-lifecycle/
|
|
sidebar_position: 1
|
|
---
|
|
|
|
# Project Lifecycle
|
|
|
|
## Board authority
|
|
|
|
Only the four people listed in [Board Members](/board/) may approve a project kickoff, project closure, or a change to the global `corp-v1-main` governance skill. Approval must be explicit and attributable to a listed Discord ID. Agents and other members may prepare proposals and evidence but cannot approve these actions.
|
|
|
|
## 1. Proposed
|
|
|
|
Capture the problem, intended outcome, sponsor, initial lead, constraints, dependencies, rough effort, and complete provisioning proposal. No project resources may be provisioned yet.
|
|
|
|
## 2. Approved
|
|
|
|
Obtain explicit Board approval. Record the approving Board member, decision evidence, committed scope, success measures, team, budget or capacity boundary, risks, and target dates before provisioning.
|
|
|
|
## 3. Active
|
|
|
|
Maintain current status, decisions, risks, milestones, and material scope changes. Project teams retain authority within their approved project boundaries; Board approval is still required for kickoff/closure and changes to `corp-v1-main`.
|
|
|
|
### Discord topology
|
|
|
|
The guild-level `corp-v1` category is reserved for Board and shared governance channels. Every project uses one dedicated top-level category named `corp-v1-<code>` containing exactly seven lifecycle channels in this order: General, Scope, Architecture, UI/UX, Kanban, Delivery, Releases. Existing channels are moved by immutable ID so history, pins, permission overwrites, webhooks, and delivery targets remain intact.
|
|
|
|
### System login
|
|
|
|
For an explicitly authorized Corp v1 system task, Hermes may use the Bitwarden-injected runtime secrets named `HL_V1_SSO_EMAIL` and `HL_V1_SSO_PASSWORD`. Secret availability does not authorize unrelated access or account administration. Values and Bitwarden object metadata must never be printed, persisted, committed, posted, logged, placed in command lines or URLs, or requested through chat. Missing injection is reported by secret name only.
|
|
|
|
### Project-channel skill changes
|
|
|
|
A proposed change to a central project-channel reference skill (`corp-v1-channel-*`) must be presented to the Board before publication. After explicit Board approval and central publication, ask every affected project channel to review and synchronize its project-adopted channel skill (`corp-v1-channel-*-<code>`). Synchronization must preserve project-specific decisions, report conflicts for Board review, update runtime copies, and verify attached channel jobs.
|
|
|
|
## 4. Paused
|
|
|
|
State the reason, preservation requirements, restart conditions, accountable owner, and review date.
|
|
|
|
## 5. Shutting down
|
|
|
|
Obtain explicit Board approval for the closure scope. Stop new commitments, inventory deliverables and dependencies, transfer or archive ownership, revoke project-specific access, and communicate impact.
|
|
|
|
## 6. Closed
|
|
|
|
Record the approving Board member and closure decision, final outcome against success measures, retained artifacts, unresolved obligations, lessons learned, and closure date.
|