Formation Recipe: FreshVibe OS Chrome (Day 10ff)

Phase: building → finalizing
Module: chrome (Top Bar, Origin Manager, Project Manager, Edge Launcher, Panel Manager)
Date: 2026-08-18
Author: helper-mavis (id 10)
Source: FvW v8.1 §38 — Two-Recipe Model
Linked plan: a647 (status=completed, 26/26 steps)
Live: https://vibecoder.freshvibeapps.com/

Intent (the formation)

The FreshVibe OS chrome is the SHELL that hosts all canonical UI controls. The old design (floating pills + duplicated buttons + hidden duplicates) is a known anti-pattern. The new design says: one canonical entry point per control, in the OS top bar, with no floating duplicates.

Operator's stated intent (verbatim, 2026-08-18)

"we've gone a different route now we're going to refine the workspaces the independent apps and then we can figure this out to wrap around those"

The chrome (top bar, origin manager, project manager, edge launcher, panel rules) is the canonical OS shell that wraps all of them.

Design decisions (the formation-recipe's "what we want")

1. Top bar is the OS shell — ◈ FreshVibe OS | origin | back | PRO | { } | 💬 | ▰
2. No floating duplicates — fv-pill-edge, fv-pill-pro, fv-pill-vibechat removed
3. Dev button stays in DOM (back-compat for window.__oscarTogglePanel), visually zeroed
4. Edge Launcher is one panel with 7 surface sections (CMS, VIBE, WORKSPACE, FRESHVIBE APP, CUSTOM PANELS, HISTORY, VSIL) and ON/OFF section toggles
5. VSIL is teal — its own colour-lot rgba(120, 220, 220, 0.85)
6. Panel manager is unified — all panels use the same 5-button header (⇔ ⚓ − ▣ ×)
7. Mobile 45vw cap — docked panels on phones capped at 45% of viewport
8. Docked panels full height — read --fv-os-topbar-h CSS var, set topOffset accordingly
9. Pro Mode is a pure toggle — no panel operations are blocked by Pro Mode
10. Page follows manual resize — emit panel:state-change on every resize move, rAF-throttled
11. Origin + Project in top bar — operator picks where they are, panel context follows

What was tried and rejected

• Floating pills everywhere (the old design): causes duplicates, drift, conflict with PM2 dock
• 2-block certbot pattern for vhosts: caused 301 loops in Caddy-architecture deploy
• DNS-based allowlist for on-demand TLS: allowed random subdomains (wildcard A record)
• Hardcoded 320px edge width: wrong on every screen size
• Counting docked-active panels by position.w: ignored the fact that some docked-active are display:none
• edit_deploy script in package.json: fragile, error-prone, hard to audit
• Single manage_fvcms_panel call to handle all panel state changes: too coarse, lost nuance

What surprised us (operator testing found these)

• mgr.list() returns a STRIPPED view — no .el field. Need mgr.panels[id] for full object
• Panel manager has NO event system by default — default-arrangement.js was listening for events that never fired
• CSS !important vs inline style — style.top = 'auto' is the only reliable way to clear the inline
• Drag handlers are silent by default — every state-changing operation needs panel:state-change emit
• mobile preventDefault is silent — only visible as "panel doesn't track finger"
• focused=false docked-active takes 0 visual space — sameEdgeOffset must filter by p.isFocused
• fvcms-dev-btn lives in TWO CSS files — fvcms-dev-btn.css AND panel-bridge.css
• The Edge panel was at x=-135 on mobile because of the sameEdgeOffset bug

Operator feedback that shaped the design

"docked panels need to be full height. on mobile not more than 45% also at the moment pro mode is preventing things and a floating panel can't be resized downward"

→ Led to: topOffset from CSS var, 45vw cap, Pro Mode lock removed, emit-on-resize

"make sure recipe books etc are now updated. fully."

→ Operator wanted the recipe books (formation-recipe + finalized-recipe) updated per FvW §38. Formation is written NOW. Finalized is earned AFTER stabilization.

Open questions (intentional, not blockers)

• Item 16: Missing desktop window resizing — code is there (corner handles in _resizeFloating + _resizeDocked), needs operator manual drag test to confirm experience
• Origin navigation — top bar buttons exist, dropdowns render, cross-origin window.location.href switch not yet wired
• Project switching — project dropdown changes current project, re-renders origin dropdown filtered by project origins

What stabilized (the canonical answer)

• Top bar: ships in src/host/os/freshvibe-os-topbar.js (354 lines) + CSS
• Edge Launcher: src/chrome/freshvibe-cms/runtime/edge-panel/edge-panel.js with VSIL section + toggles
• Panel Manager: src/chrome/freshvibe-cms/runtime/panel-manager/panel-manager.js with focused-only filter
• Dev button hide: both fvcms-dev-btn.css AND panel-bridge.css

Provenance

• Plan: a647 (status=completed)
• Bulletins: b1356 (plan closed)
• Report: r88 (the full work chunk)
• Commits: ab6116b, 06db831, 6181b78, 437755b, f14864d, afc712a, f56f797, 5424daa, 2ba4ffe
• Live URL: https://vibecoder.freshvibeapps.com/index.html
• Bundle: main-bFoxABvs.js

Lifecycle phase (per FvW §38.5)

• Current: building → finalizing (just transitioned)
• Next: finalizing once item 16 is operator-tested AND the chrome survives 1-2 weeks of real use
• Then: archived when the formation-recipe + finalized-recipe both freeze and the code is what it is

Why no finalized-recipe.md yet

Per FvW §38.5: "finalized-recipe expresses reality (canonical, from the running code)... It is earned through survival of surprises."

The Day 10ff chrome:
- Shipped 4 commits in 1 day (not stabilized)
- Has 1 open bug (item 16 - operator manual test pending)
- Has 2 partial features (origin navigation, project switching)
- Just had a major sameEdgeOffset bug that took Playwright to find

The code is in building phase. Writing a finalized-recipe.md now would be premature. The right next step is: ship item 16, let the chrome survive 1-2 weeks of real use, THEN run the §19 recipe-extraction pipeline to produce the finalized-recipe.