jarvis-at-skic
d1bb6f8b18
3.1 KiB
title, description, slug, sidebar_position
| title | description | slug | sidebar_position |
|---|---|---|---|
| Project Lifecycle | Apply the Board-controlled lifecycle for starting, operating, synchronizing, and closing Corp v1 projects. | /project-lifecycle/ | 1 |
Project Lifecycle
Board authority
Only the four people listed in Board Members 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.