Jeffrey Smith
748da6c2b4
Custom team roles: removed CHECK constraint on team_members.role, roles stored in teams.settings, roles API, stage_config.required_role enforced on claim. Multi-party signoff: workflow_signoffs table, validation gate in advanceInternal, SubmitSignoff engine method, signoff HTTP API. Frontend: dynamic role management, stage config validation UI, signoff panel. Design docs for extension lifecycle and trigger composition. 20 store tests passing. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
50 lines
2.0 KiB
Markdown
50 lines
2.0 KiB
Markdown
# Extension Lifecycle: Permanent vs PoC
|
|
|
|
## Overview
|
|
|
|
Packages (extensions) fall into two categories: **permanent** and **PoC** (proof-of-concept).
|
|
This classification drives install-by-default behavior and maintenance expectations.
|
|
|
|
## Permanent Packages
|
|
|
|
Permanent packages are part of the platform kernel or essential surfaces. They are always
|
|
available and maintained by core contributors.
|
|
|
|
| Package | Reason |
|
|
|------------------|--------------------------------|
|
|
| admin | System administration surface |
|
|
| team-admin | Team management surface |
|
|
| settings | User settings surface |
|
|
| login | Authentication surface |
|
|
| welcome | Onboarding / empty-state |
|
|
|
|
## PoC Packages
|
|
|
|
Everything else in `packages/` is PoC. These demonstrate the extension model but are not
|
|
required for platform operation. Examples: tasks, schedules, dashboard, editor, git-board,
|
|
icd-test-runner, sdk-test-runner.
|
|
|
|
Retired builtins (csv-table, diff-viewer, js-sandbox, katex-renderer, mermaid-renderer,
|
|
regex-tester) are PoC packages migrated from the kernel during the v0.2.9 retirement.
|
|
|
|
## Graduation Criteria
|
|
|
|
A PoC package may be promoted to permanent when all of the following are met:
|
|
|
|
1. **Active usage** — 3+ active users or teams depend on it.
|
|
2. **Test coverage** — At least basic smoke tests exist (Starlark or integration).
|
|
3. **No kernel special-casing** — The package operates entirely through the public extension
|
|
API. No `if pkg == "X"` branches in core.
|
|
4. **Documentation** — README with install instructions, config options, and screenshots.
|
|
5. **Maintenance owner** — A named contributor commits to reviewing issues.
|
|
|
|
## Deprecation
|
|
|
|
Packages that no longer meet graduation criteria (e.g., zero usage for 6 months) may be
|
|
archived. Archived packages remain installable but receive no updates.
|
|
|
|
## Install Model
|
|
|
|
All packages use explicit installation: `POST /api/v1/packages/:id/install`. There is no
|
|
auto-install. The kernel ships clean; teams choose what they need.
|