# 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.