Jeffrey Smith
0773c86c27
Co-authored-by: Jeffrey Smith <jasafpro@gmail.com> Co-committed-by: Jeffrey Smith <jasafpro@gmail.com>
2.0 KiB
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:
- Active usage — 3+ active users or teams depend on it.
- Test coverage — At least basic smoke tests exist (Starlark or integration).
- No kernel special-casing — The package operates entirely through the public extension
API. No
if pkg == "X"branches in core. - Documentation — README with install instructions, config options, and screenshots.
- 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.