ID10 — Settings System Audit & Architecture Plan
**Date**: 2026-08-20
**Status**: PLANNED (not yet built — saved for later per operator directive 2026-08-20 19:46: "we may add a settings system to the pack")
**Source**: Operator-supplied audit on 2026-08-20 20:34 CEST, full text captured in the chat history of session 412100071272671
**Refs**: 12 greyed Edge tiles (commit e8cd1e3) reference this; bulletin b1511
OVERVIEW
FreshVibe currently has settings scattered across multiple subsystems with no unified architecture. CMS settings, App settings, Developer settings, VibeCoder engine settings, FVRE runtime settings, FES backend settings, workspace/project settings, panel library settings, AI tools settings, and credential/security settings all exist — but they are fragmented, duplicated, or hidden.
This audit identifies:
1. All existing settings
2. All implicit settings
3. All future settings FreshVibe will require
4. Correct subsystem boundaries
5. A unified Settings System architecture
6. A plan for implementation
SECTION 1 — CMS SETTINGS (REAL + HIDDEN + FUTURE)
CMS is an app-level editor. Its settings must remain separate from global settings.
**REAL**:
- Theme/Skin (colour, variant, contrast, accent, background, font, spacing, radius, shadows)
- Modules (enable/disable, order, visibility, region binding)
- Regions (visibility, overlays, inspector, content source)
- Group mode (on/off, highlight)
- Runtime modes (strict, soft, live, preview)
- Extraction/regeneration modes
**HIDDEN**:
- CMS auto-sync
- CMS auto-publish
- CMS regeneration strictness
**FUTURE**:
- CMS presets
- CMS export/import
- CMS sync
- CMS permissions
- CMS content source presets
- CMS layout presets
**BOUNDARY**: CMS settings belong in **Settings → CMS**, not in global Settings.
SECTION 2 — APP SETTINGS (REAL + FUTURE)
App settings are currently split between CMS and metadata.
**REAL**:
- App name
- App icon
- App theme (duplicate of CMS Skin)
- App modules
- App regions
- App metadata
**FUTURE**:
- App branding
- App typography
- App layout
- App transitions
- App animations
- App caching
- App performance mode
- App export/publish
- App rollback/versioning
**BOUNDARY**: App settings belong in **Settings → App**, not CMS.
SECTION 3 — DEVELOPER SETTINGS (REAL + FUTURE)
Dev panel contains developer-facing settings.
**REAL**:
- Theme picker (duplicate of CMS Skin)
- Engine selection
- Engine fallback
- Engine strictness
- Engine regeneration strictness
- Behaviour inference mode
- Logging verbosity
- Console visibility
- Build mode
- Hot reload
- Error overlay
**FUTURE**:
- Debug presets
- Build targets
- Sandbox mode
- Performance profiling
- Developer permissions
**BOUNDARY**: Developer settings belong in **Settings → Developer**, not Dev panel.
SECTION 4 — VIBECODER SETTINGS (REAL + FUTURE)
VibeCoder has many real settings but no UI.
**REAL**:
- engine
- engineFallback
- engineStrictness
- engineRegenerationStrictness
- behaviourInferenceMode
- extractionStrictness
- extractionMode
- extractionDepth
- regenerationStrictness
- regenerationMode
- regenerationDepth
- workspaceRoot
- workspaceMode
- workspaceStrictness
- workspaceFallback
**FUTURE**:
- AI model selection
- AI model fallback
- AI strictness
- AI behaviour profiles
- AI hallucination guard
- AI safety mode
**BOUNDARY**: VibeCoder settings belong in **Settings → VibeCoder**.
SECTION 5 — FVRE SETTINGS (REAL + FUTURE)
FVRE runtime engine settings are real but hidden.
**REAL**:
- runtime extraction
- runtime regeneration
- runtime strictness
- runtime fallback
- runtime behaviour inference
- runtime DOM extraction
- runtime DOM streaming
**FUTURE**:
- runtime caching
- runtime performance mode
- runtime sandbox mode
- runtime permissions
- runtime error handling
- runtime logging
- runtime profiling
**BOUNDARY**: FVRE settings belong in **Settings → Runtime Engine**.
SECTION 6 — FES SETTINGS (REAL + FUTURE)
Backend engine settings are scattered.
**REAL**:
- FES endpoint
- FES workspace
- FES project
- FES sync mode
- FES build mode
- FES hot reload
**FUTURE**:
- multi-project support
- permissions
- API keys
- deployment targets
- versioning
- rollback
- diff mode
- safe mode
**BOUNDARY**: FES settings belong in **Settings → Backend Engine**.
SECTION 7 — WORKSPACE & PANEL LIBRARY SETTINGS (FUTURE)
These were incorrectly placed in Edge as ghost tiles.
**FUTURE**:
- Workspace presets
- Workspace switching
- Workspace A/B testing
- Workspace export/import
- Workspace sync
- Workspace permissions
- Panel library (manage/export/import/sync)
- Panel presets
- Panel permissions
BOUNDARY**: Workspace settings → **Settings → Workspace** | Panel library settings → **Settings → Panels
SECTION 8 — AI TOOLS & CREDENTIAL STORE (FUTURE)
AI Tools is a future subsystem. Credential Store is essential.
**FUTURE**:
- AI engine
- AI fallback
- AI strictness
- AI behaviour profile
- AI hallucination guard
- AI safety mode
- Credential Store (API keys, provider tokens)
- Model selection
- Model permissions
BOUNDARY**: Credential Store → **Settings → Security → Credentials** AND → **Settings → AI Tools → Credentials
SECTION 9 — SETTINGS SYSTEM ARCHITECTURE PLAN
A. SETTINGS REGISTRY (single source of truth)
Each setting defined with:
- id
- category
- type
- default
- storage
- scope
- ui
- permissions
B. SETTINGS API
- getSetting(id)
- setSetting(id, value)
- listSettings(category)
C. UNIFIED SETTINGS PANEL (master panel)
Categories:
- General
- Appearance
- CMS
- App
- Developer
- VibeCoder
- Runtime Engine (FVRE)
- Backend Engine (FES)
- Workspace
- Panels
- AI Tools
- Security
D. SUBSYSTEM SETTINGS PANELS
Each category gets its own panel.
E. MIGRATION PLAN
- Remove ghost tiles from Edge
- Move Dev → Settings tab into Settings System
- Treat CMS Skin as CMS Settings
- Move Credential Store into Settings → Security + AI Tools
- Create App Settings panel
- Create Workspace + Panel Library panels
OPEN QUESTIONS / PENDING
1. **When to build**: operator has not yet scheduled. Edge Launcher shipped with the 12 greyed tiles (2026-08-20 e8cd1e3) as honest "soon" signals.
2. **Effort estimate**: 1-2 weeks for full implementation
3. **First slice**: Settings → General + Settings → Appearance (low risk, useful) or Settings → Security → Credentials (high value, gating)
4. **CMS subsystem lock**: CMS is vendored, so CMS Settings must ship via CMS source then re-vendored, not via host config
5. **Cross-app portability**: Settings Registry is the same for any FreshVibe-built app, so the first app to need it gates the API shape
END OF ID10 AUDIT & PLAN