jarvis-at-skic
6170e09db6
Build and publish Corp v1 Board portal / build (pull_request) Successful in 35s
41 lines
2.2 KiB
Markdown
41 lines
2.2 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 six 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`.
|
|
|
|
### 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 that no Corp v1 scheduler job exists.
|
|
|
|
## 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.
|