Feat v0.3.4 team roles signoff (#18)

Co-authored-by: Jeffrey Smith <jasafpro@gmail.com>
Co-committed-by: Jeffrey Smith <jasafpro@gmail.com>

docs/DESIGN-EXTENSION-LIFECYCLE.md

@@ -0,0 +1,49 @@
+# 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.