Feat v0.2.6 admin settings audit (#10)
Some checks failed
CI/CD / detect-changes (pull_request) Successful in 4s
CI/CD / test-frontend (pull_request) Failing after 5s
CI/CD / test-go-pg (pull_request) Failing after 2m37s
CI/CD / test-sqlite (pull_request) Successful in 2m51s
CI/CD / build-and-deploy (pull_request) Has been skipped

Roadmap reorder: Extension Lifecycle moved to v0.3.x, settings audit
milestones renumbered (v0.2.7→v0.2.6, v0.2.8→v0.2.7, v0.2.9→v0.2.8).
Added v0.2.9 for builtin extension retirement — 6 chat-centric
extensions (csv-table, diff-viewer, js-sandbox, katex, mermaid, regex)
are dormant until a chat surface ships; roadmap tracks converting them
to regular packages and removing the auto-seed mechanism.

Admin settings E2E verified — all 7 sections (default surface,
registration, banner, message bar, footer, vault, email) render and
save correctly. Packages surface verified (17/17 loaded).

Dead code removed:
- sectionCategory(): AI/routing/channel cases, default→system
- PublicSettings(): system_prompt, retention_ttl, paste_to_file,
  allow_user_personas
- PolicyDefaults: allow_raw_model_access, default_model
- Profile handlers: allow_raw_model_access, kb_direct_access lookups
- Test seeds: model_roles setting, allow_raw_model_access policy
- packages.js: 'chat' from CORE_IDS

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-03-27 15:03:10 +00:00
parent 3cc3360624
commit 64890bf12f
9 changed files with 58 additions and 77 deletions

View File

@@ -89,42 +89,45 @@ SDK stabilization, and the first rebuilt extension (tasks).
| Default surface routing | ✅ | Resolution chain: user preference → global config → first extension → `/welcome`. Users can set personal default in Settings > General. Admin sets global default in Admin > Settings. |
| Admin navigation | ✅ | Replaced Back button with UserMenu in admin topbar. Eliminates back-button infinite loop. |
### v0.2.6 — Extension Lifecycle
### v0.2.6 — Admin Settings Audit
| Step | Status | Description |
|------|--------|-------------|
| Extension lifecycle | | Define permanent vs PoC extensions. Package graduation criteria. Dependency policy. What ships with core vs what's installed separately. |
| Admin settings E2E | | All 7 admin settings sections verified (default surface, registration, banner, message bar, footer, vault, email). Dead code removed: `sectionCategory()` pruned of AI/routing/channel vestiges, `PublicSettings()` stripped of chat-era fields (system_prompt, retention_ttl, paste_to_file, allow_user_personas), dead `PolicyDefaults` removed (allow_raw_model_access, default_model), dead policy lookups removed (kb_direct_access), test seed data cleaned. |
| Packages surface | ✅ | Package list loads (17 total/17 enabled), type filters work, enable/disable visible, settings/export buttons present, core package (admin) protected. Removed dead `chat` from CORE_IDS. |
### v0.2.7 — Admin Settings Audit
| Step | Status | Description |
|------|--------|-------------|
| Admin settings E2E | ⬚ | Verify all surviving admin settings work end-to-end: default surface, registration, banner, message bar, footer, vault, email. Remove any handler/store vestiges of deleted settings (search, compaction, memory). |
| Packages surface | ⬚ | Verify packages page correctly shows installed vs available. Enable/disable works. Broken post-fork surfaces identified and either fixed or marked. |
### v0.2.8 — User Settings Audit
### v0.2.7 — User Settings Audit
| Step | Status | Description |
|------|--------|-------------|
| User settings E2E | ⬚ | Verify all user settings sections: General (default surface), Appearance (theme, scale, font), Profile (display name, avatar, handle), Connections, Notifications. Remove dead features, fix broken states. |
| Visibility gating | ⬚ | Ensure settings sections only show features that are actually available. Hide empty sections. Respect `user_overridable` flag from extension manifests. |
### v0.2.9 — Team Admin Settings Audit (Pass 1)
### v0.2.8 — Team Admin Settings Audit (Pass 1)
| Step | Status | Description |
|------|--------|-------------|
| Team admin E2E | ⬚ | Verify team member management, team settings cascade, role assignment (admin/member). Audit for dead code from pre-fork team features. First pass — validates current functionality before v0.3.x adds team roles. |
| User settings team tab | ⬚ | Verify the Teams section in user settings — team list, join/leave, team-scoped settings. |
### v0.2.9 — Builtin Extension Retirement
| Step | Status | Description |
|------|--------|-------------|
| Retire builtin seeder | ⬚ | Stop auto-seeding chat-centric extensions (csv-table, diff-viewer, js-sandbox, katex-renderer, mermaid-renderer, regex-tester). Remove `SeedBuiltinPackages`, Dockerfile COPY, and `extensions/builtin/` directory. These extensions are not OBE — they're dormant until a chat surface exists to consume them. |
| Convert to regular packages | ⬚ | Repackage the 6 extensions as standard `.pkg` archives in `packages/`. Add chat dependency metadata to manifests so they can be installed when the chat extension ships post-MVP. No auto-install — explicit install only, matching the distribution model. |
## v0.3.x — Workflow Architecture
Workflows are the core platform capability. This series implements the
full multi-step automation system with team role integration.
full multi-step automation system with team role integration and
finalizes the extension lifecycle model.
### v0.3.0 — Workflow Design + Schema
| Step | Status | Description |
|------|--------|-------------|
| Extension lifecycle | ⬚ | Define permanent vs PoC extensions. Package graduation criteria. Dependency policy. What ships with core vs what's installed separately. |
| Workflow design session | ⬚ | Define what "workflow" means in the extension-first model. Determine if the existing `workflows` table/handler survives, gets rebuilt, or gets removed. Document the Starlark contract for multi-step automation. See `docs/DESIGN-WORKFLOW-REDESIGN-0.2.6.md`. |
| Team roles | ⬚ | Different roles per team responsible for different workflow stages. Role-based stage assignment, multi-party validation (2-party sign-off at stage boundaries). |
| Trigger composition model | ⬚ | How do triggers, schedules, and workflows compose? Event chains, conditional branching, error handling. Design doc before code. |