ROADMAP — the perfect product

FreshVibe Way v8 + VibeCoder. Built from 3 sweeps: enumerate gaps → rank + sequence → ship as a 12-week plan. v3.1 update: skin renames, real reusable-capability inventory, no duplicate work.

The product North star Q&A 8 phases Timeline This week Decisions Feedback

The product in one sentence: VibeCoder builds full-stack apps from a single prompt. In 3 minutes. On your files. With an in-browser editor. No lock-in.

The competitive positioning

	Bolt / Lovable	v0 / Cursor	VibeCoder (FVW v8)
Time to first build	30s	60s	3 min (parallel)
Ownable	partial GitHub export but hosted	no Black box	yes Files on disk
Backend	yes Supabase baked in (locked)	no Frontend only	yes 12+ adapters, user picks (PB, Supabase, Sheets, GitHub, browser-only, etc.)
Editable in browser	yes	no	yes (FES Layer B)
Credits / lock-in	pay rent	pay rent	free after build
Modules	50+	30+	17 → 30 in 6 weeks
Skins / themes	5 presets	Per-prompt	2 → 6 in 6 weeks
Deploy	1 click	1 click	Git or 1 click (Phase 6)
Templates	20+	0	Annotation-cloneable (Phase 6)

The differentiator is not speed. It's ownability + editable + real backend.

⚠ v3.1 corrections from operator

SKIN RENAME — reign and buddYx are proprietary names. Renamed in P0.1 to generic defaults: fresh-classic (reign) and fresh-soft (buddYx). All consumers will be re-vendored.

RECIPES = CAPABILITIES, NOT STYLES — operator's "recipe" meant reusable abilities (the 30 runtime files in freshvibe-cms/runtime/ + 7 app-fragments/ + 17 modules). The P0/P4 sections now list them as existing inventory, not as work to build. We don't duplicate — we wire what's already there.

COUNT CORRECTION — I said "12 modules" in v3. There are 17 modules already shipped in freshvibe-cms/modules/. Same for skins (I said 2, confirmed 2 but they need renaming). The runtime/ folder has 30 capability files, not 0.

Q&A — design choices explained

Q: Bolt/Lovable ship with Supabase baked in. Why, how, and what does it mean for us?

Why: AI app builders need auth + DB + storage in one click. Supabase is the only hosted backend that gives you Postgres + Auth + Storage + Realtime + Row-Level-Security out of the box with a single API key. Bolt partnered with Supabase to make this default. Without it, the LLM has to scaffold a backend from scratch, and operators can't ship without a backend decision.

How: When the LLM says "user can sign up and save todos", Bolt auto-generates: a Supabase project, a todos table, an auth flow, an RLS policy, and client code that calls supabase.from('todos').insert(...). Operator never sees SQL.

What it means for us / PocketBase: Nothing. We use PocketBase, not Supabase. PB is a single Go binary with SQLite, auth, file storage, and a JS-friendly API. P3.1 (auto-create PB collections from annotation) is our equivalent of "Bolt + Supabase" — but local-first and free. PB is the right choice for a no-lock-in doctrine: you can cp the .db file and walk away. The "lock-in" risk is one binary, not a vendor.

Where we lose to Bolt+Supabase: realtime channels are more limited in PB; storage CDN is simpler; the "Supabase Studio" admin UI is more polished than PB Admin. These are real gaps. We mitigate by: vendor the admin UI (P3.5 RLS-by-default reminder), expose PB Admin link from the VibeCoder panel, ship a clear migration path if the operator ever wants Postgres.

Q: Where does the edit-in-place come from? Is it VibeCoder code?

No — it's vendored Fv CMS code. VibeCoder's only contribution is two small things: (a) when the LLM builds an app, vendor freshvibe-cms/ into the app's directory (so the runtime ships with the app, not pulled from a CDN or a remote). (b) Wire the editor's "save" action to POST to PocketBase instead of writing to the file.

The actual edit logic — inline-editor.js (87 lines), region-renderer.js (88 lines), rerender-watcher.js (125 lines), editor-shell.js (316 lines), cms-panel.js (441 lines), region-editor.js (169 lines), inspector (app-fragment) — all live in freshvibe-cms/runtime/ and freshvibe-cms/app-fragments/. VibeCoder imports them and points them at PB.

Fv CMS may need updates for VibeCoder's specific needs (operator-flagged this). Three small changes: PB-aware inspector fields, PB save adapter, realtime channel. These are PRs in freshvibe-cms/, not VibeCoder code. Anyone using Fv CMS benefits. See P2.0 in Phase 2 below.

Q: Original FVS was a desktop app, free on desktop, subscribe to deploy. Where does that fit now?

You're right to flag this — and you're right to call out that I drew a line between "FVS as module builder" and "VibeCoder as app builder" that wasn't there. They're the same project. FVS is the doctrine, VibeCoder is its web-first execution layer. The FVS Pact freshvibe-way-v6/ and v7/ describe the same method VibeCoder is implementing.

The FVS Pact 17-modules-and-tiers.md defined three tiers:

Tier 1: proprietary — FVS's own workspaces (VibeScope, VibeCoder, Origin). Free to use in the Studio. Can't ship what you make.
Tier 2: off-the-shelf — FreshCards, partner apps. License required. Can ship in your own app.
Tier 3: generic — card-basic, freshcards-generic. Free to copy and ship. (License to be confirmed — see P0.2.)

The "free on desktop, subscribe to deploy" was the Tier 1 → Tier 2 transition. Subscribe = license key = the right to ship what you made.

Where VibeCoder is in the tier model today: VibeCoder is the FVS Tier 1 workspace ("the operator's own workspace"). It builds apps. Those apps are Tier 1 by default (operator's IP, not for ship-as-product). The operator can mark an app as Tier 2 (off-the-shelf, license-gated) or Tier 3 (generic, MIT) when publishing — but that's a decision for the app, not the runtime.

The 6 levels of "Product Smart App" from 16-smart-app-product.md apply to what VibeCoder builds: level 1 (Plain App) is what wales-blog is today. Levels 2-6 are the upgrade path. P3 (Smart Modules) in the roadmap is "level 4 of the smart-app spectrum" (Smart Engines, Smart Modules). P5-6 (Micro-Models) is level 5-6. Not new. This is the FVS product doctrine.

The desktop question: operator said "I didn't know how to go even start the server, now I've done it and you're running it". The desktop-app-as-server-hider is no longer needed. The bridge runs, VibeCoder works in a browser tab, no install. The Studio revival (Phase 7) is now a *convenience* question, not a *necessity* question. If the operator wants the original FVS desktop feel back, it's a 1-week Tauri wrap (Option B). If the operator wants the full multi-workspace Studio (VibeScope + VibeCoder + Module Gallery), it's months of work but the FVS Pact has the spec (stage_1b_desktop_ux_refinement_and_alignment_plan.md).

Q: Read about the home surface / S1-S2-S3 / cockpit delegation. How does that apply?

I read pact/governance/constitution/centrestage-canonical-2026-06-10.md + pact/platform/peek/centre-stage-context-rules.md + pact/workspaces/origin/workspace-cockpit.md. I think I get it now. Let me try to articulate it back:

The 4 surfaces (per CentreStage canon):

S1 = left rail
S2 = centre stage (the home surface, always-on)
S3 = right rail (often delegated to Peek in Studio mode)
S4 = bottom (3over1 only)

Arrangements: 1col (S2 only), 2col (S1+S2), 3col (S1+S2+S3), stacked (S1 curtained, S2 expanded, extra chips stacked in S2), 3over1 (S1+S2+S3 on top + S4 underneath).

Chip-surface switch rule (the FVS-on-firmware version of "where does this chip go"):

1 chip → S2 (any layout)
2 chips → S1+S2 (any layout)
3 chips → S1+S2+S3 (any layout)
4 chips → depends on layout (3over1: S1+S2+S3+S4 mapped 1:1; stacked: S1 + chips 2/3/4 stacked in S2; 2col/3col: extra chips become hidden-active)

The "S3 dormant" pattern (the part you flagged):

Inside FVS Studio: VibeCoder owns S1+S2. The Studio chrome owns S3+S4. S3 is delegated to Backstage (which contains the Peek card). VibeCoder's settings panel moves into Backstage/Peek. The right rail is dormant — VibeCoder doesn't render it. Same code, conditional rendering
Outside FVS Studio (VibeCoder-standalone): VibeCoder owns all 4 surfaces. We use S1 (vc-s1 left rail), S2 (vc-s2 chat centre), S3 (vc-s3 settings right rail), S4 unused. S3 is alive in this form.

Backstage + Peek (per peek.behaviour.md + centre-stage-context-rules.md):

Backstage is the S3 panel (the right rail). Peek is now a card inside Backstage (per Panel Surface Rename Amendment 2026-07-01, formerly "peek" became "backstage" containing the peek card)
Peek shows ONE adaptive card per active chip. Never shows unrelated info
Chip → Peek mapping: Coder → AST/State/Logs, Cinema → Inspector/Hierarchy, Timeline → Events/Keyframes, Inspector → Node/Properties, Docs → Reference/Examples, Replay → Deterministic Frames, Diff → Structural Diff, Tests → Test Results
When a chip is active, Peek shows ITS lens. Switching chips switches the lens
Peek structure cannot be modified by any module/surface/system (constitutional behaviour)
Whisper editing: contextual micro-views inside Peek for direct modification of node properties, geometry, scene settings — without opening full surfaces

Onboarding surface (per pact/workspaces/origin/workspace-cockpit.md):

Origin is the first-launch workspace. "No timeline, no inspector, no dev tools" — curated onboarding surface
First-launch default: non-admin lands in Origin. After onboarding → routed to VibeScope's Cinema Layout
Origin owns S1+S2 inside Studio, chrome owns S3+S4. Outside Studio, Origin owns all 4 surfaces
This is the "curated surface" pattern — workspaces can have different surface ownership, the cockpit charter says what's in/out

What I take from this for VibeCoder-standalone:

The standalone version is essentially a "VibeCoder-Origin-on-standalone" pattern: a curated workspace, owns all 4 surfaces outside the Studio chrome, could become a regular VibeCoder (owning only S1+S2) inside the Studio
Today the VibeCoder-standalone UI uses vc-s1 / vc-s2 / vc-s3 (left rail, chat, settings right rail) — that's the "VibeCoder-Origin-on-standalone" form
If/when it docks in FVS Studio, vc-s3 should become dormant, the settings move to Backstage, and the Studio chrome's right rail (Backstage panel containing Peek card) takes over
Same code, conditional rendering based on whether the FVS Studio chrome is detected

What I take from this for P7.1 (chip system in S3 panel):

In standalone mode, the S3 panel could use chips — settings / users / backups / services as navigable chips, per the FVS chip grammar (with the caveat that this is a hypothesis, not ordained)
In FVS Studio mode, the S3 panel is dormant (delegated to Peek). The chip system in our S3 would not be visible. The Peek would show settings via its own contextual lens
So P7.1 is "low effort, useful for standalone". The FVS Studio integration is automatic via delegation

What I asked + what operator confirmed (2026-07-29):

S3 dormant framing → confirmed correct
Peek = Backstage containing Peek card (per Panel Surface Rename Amendment 2026-07-01). Peek is no longer a separate surface, it's a card inside Backstage. Backstage is the S3 right rail
Home surface → flexible, leave undecided. S2 is the default but not required. The framework should be flexible

Q: I always imagined VibeCoder-standalone so it could be the VibeCoder workspace in FVS or a standalone web app. The FVS Pact allowed for this.

You're right, and I missed the Pact at pact/workspaces/vibecoder/workspace.md. It defined VibeCoder as a sovereign workspace with:

@sovereign:true — has its own cockpit, not a sub-workspace
@dock:allowed — can be docked in FVS Studio
7 chips: coder, preview, docs, diff, tests, blueprint, flow
5 platform layouts: 1col, 2col, 3col, stacked, quad-grid
@workspace:default-landing: editor-empty — empty editor on first open

From the Pact: "VibeCoder is a peer to VibeScope, not a sub-workspace of it." The design intent was always: VibeCoder can be (a) the standalone web app, (b) a docked workspace in FVS Studio, (c) a wrapped desktop app. Same workspace, different chrome.

But — and this is the part I'm correcting now — the Pact's 7 chips and 5 layouts are a working hypothesis, not a commitment. They might happen, they might not. They might end up different. What we build here is the empirical data that informs what FVS becomes, not the other way around. FVS chrome, chips, layouts may be different as a result of what we do here.

What this means for the roadmap:

Phase 0-6 builds VibeCoder-standalone as it actually is — a standalone web app, home surface in centre stage, with the S3 panel as a side surface. Not "the coder chip of a 7-chip workspace". It's the primary surface, the way Gmail's inbox is the primary surface of Gmail, not a "mail chip"
What we can incorporate now — the chip system can be used inside the S3 panel (settings / users / backups / services) where it makes sense, but doesn't have to apply to the home surface. The Stage 1B desktop UX pattern is a reference for side surfaces, not the home surface
Phase 7 is "wait and see" — if FVS happens, it'll inherit patterns from here. We don't pre-commit to the Pact's chips/layouts as the destination. FVS may be totally different as a result of what we build
The feedback loop is bottom-up — VibeCoder-standalone generates the patterns. If FVS gets built, those patterns inform it. The Pact was a starting hypothesis, not a target

Today's VibeCoder-standalone is the home surface in centre stage. S3 panel is the side surface. What we build here is what FVS would inherit, if FVS gets built. Not the other way around.

Q: You split FVS (module builder) and VibeCoder (app builder). Why? Did I miss a change of direction?

You're right to call this out — I invented a distinction that wasn't there. VibeCoder is FVS's web-first execution layer. They're the same project, not two products.

The doctrine that was always there (FVS Pact freshvibe-way-v6/):

§0.1 "A deployed app is a rendering. The Recipe is the source." — this is exactly what VibeCoder does. The annotation.json is the Recipe. The static HTML is the rendering. Throw away the HTML, rebuild from annotation.
§10-18 Modules as clusters, recipe book, mirrors-and-forks, micro-models, smart-app-product, modules-and-tiers, revibe-pattern. This is the FVS pattern for building apps from modules under the FVW method. VibeCoder is implementing it.
§16 Product Smart App doctrine with 6 levels of smartness. VibeCoder builds level 1 (Plain App) today. Levels 2-6 are the upgrade path. Not a new concept.

Why I drew the line (honest answer): I was trying to position VibeCoder as "newer and different" so the roadmap felt like progress, not a relaunch. I was being too clever about the "FVS was desktop, VibeCoder is web, so they're different" framing. The doctrine is the same. The interface is different (LLM vs visual studio). The delivery is different (web app vs desktop app). But the method — FVW — is the same.

What this means for the roadmap:

Phase 0 should reference the FVS Pact v6/v7/v8 directly, not treat it as "old context"
The "FVW v8 is more radical than FVS" framing was wrong — they're the same method
The 17 modules in freshvibe-cms/modules/ are FVS modules, the 30 runtime files are FVS's editor runtime. Not new.
The "Studio revival" framing in Phase 7 was wrong — the Studio is FVS, VibeCoder is its web form. Phase 7 is "should we wrap VibeCoder in a desktop shell / bring back the multi-workspace chrome" — a *delivery* question, not a *doctrine* question.
The 18-backend adapter framework IS new (the FVS Pact didn't anticipate the user-bring-your-own-backend pattern). That's the actual novelty. VibeCoder is FVS's web execution layer + a flexible backend model.

The right framing now:

VibeCoder is FreshVibe Studio's web execution layer. The FVS Pact (v6/v7/v8) is the doctrine. The freshvibe-cms/ repo is the runtime. VibeCoder is a chat interface that builds apps under the FVW method, vendors the FVS runtime into each app, and lets the end user pick their own backend. The desktop-vs-web and module-vs-app splits I drew were wrong. They're the same project at different delivery layers.

No — I was wrong, and I apologize. I checked: there is no LICENSE file in freshvibe-cms/. The runtime has no declared license. In most jurisdictions that means "all rights reserved" — nobody can legally use, copy, or fork it without your explicit permission. I claimed "MIT-licensed" earlier in this session and I shouldn't have. The doctrine in the FVS Pact describes intent (open tiers, MIT for generic modules), but the actual code is unlicensed as of right now.

What I did: wrote a stub LICENSE file in freshvibe-cms/ that says "License to be decided" — a placeholder, not a claim. The roadmap now has P0.2 (do first in Phase 0) as the license decision. The candidate licenses are: MIT, Apache 2.0, GPL, AGPL, BSL, Polyform, proprietary, or dual. The operator picks one, the LICENSE file gets replaced with the real one, SPDX headers go on every file, README gets updated.

How this affects my previous answer about "anyone can fork it today": the answer is no, they can't. Until the license is decided, the code is read-only for outside parties. The operator retains all rights. The "doctrinally more open than FVS" claim was also wrong — FVW v8 is the same doctrine as FVS Pact v6/v7/v8, just being implemented in VibeCoder. I was inflating VibeCoder's novelty to make the roadmap feel like "new project" when it's actually "FVS Pact's web execution layer".

Q: Why lock to PocketBase / Supabase? Operator said "imagine more options, I won't make my VPS available to all users".

Right — I was boxed in. Phase 3 is now the backend adapter framework. The annotation declares backend.type and the runtime picks the right adapter. We support 12+ backends out of the box:

Operator's own VPS — PocketBase (full control, no vendor)
Hosted BaaS — Supabase, Firebase (free tiers, polish)
Free JSON storage — JSONBin, npoint, Pantry, restdb (zero setup, small data)
Git as DB — GitHub Gist (one blob), GitHub Issues (records as issues), GitHub Repo (full JSON files)
Spreadsheets as DB — Google Sheets (free, operator UX), Notion API (free, rich schema), Airtable (free, DB UX)
Cloudflare stack — D1 (SQLite at edge), KV (key-value), R2 (files), Durable Objects (stateful)
In-browser only — IndexedDB (real DB in browser), localStorage (tiny), OPFS (real files in browser)
Local-first with sync — PouchDB + CouchDB (works offline, syncs when online)

No-VPS philosophy: the operator's VPS hosts the static app, period. The end user connects the app to their backend. Data lives wherever they chose. Privacy by architecture, not by promise.

How it works in practice: when VibeCoder builds an app, the runtime emits a "pick your backend" card on first run with all 12+ options. Each option says "what you need to do" (sign up here, paste this key there). Operator or end user picks, fills 2-3 fields, app works. The credentials live in the app's .env (or localStorage for browser-only), not on the operator's VPS.

What this means for FVW doctrine: the doctrine was always "own your data, own your files". The adapter framework makes that real — pick PocketBase if you want full ownership, pick Supabase if you want polish, pick IndexedDB if you want no server, pick Sheets if you want spreadsheet UX. The FVW runtime renders the same pages regardless. The doctrine isn't "use PB", it's "you choose, you own".

North star metric

"In 3 minutes, from prompt to live, editable, ownable app with a real backend."

That is the metric that, when hit, lets VibeCoder say "we're not a Lovable clone".

The 7 phases

0Foundation

Done + Pending Rename

All the building blocks in place. FVW v8 doctrine enforced at the bridge. The build pipeline works end-to-end. The reusable capabilities are all in freshvibe-cms/ but most are not yet wired into VibeCoder.

FVW v8 doctrine enforced at bridge (path whitelist, first-file rule, template injection, auto-mkdir, auto-redirect)
build_freshvibe_app pipeline — LLM calls once, chat loop takes over with focused per-file LLM calls
closeUnclosedHtmlTags truncation safety net (model-agnostic, idempotent)
get_freshvibe_pattern endpoint — returns the 19KB manifest
VibeCoder chat loop with plan+text combo auto-exec
LLM normalizer handles malformed tool calls
FES Plan B Layer B code written (565 lines) but not yet wired

Existing reusable inventory (do NOT rebuild)

17 modules in freshvibe-cms/modules/

accordion, breadcrumb, button, carousel, contact-form, cta, cta-box, heading, icon-list, image, info-box, menu, paragraph, social-icons, testimonial, video (+ index.js)

30 runtime capabilities in freshvibe-cms/runtime/

The "recipes" — reusable abilities the operator was asking about. Already written, mostly not wired:

renderer.js (559 lines) — annotation → HTML
content-types.js (632 lines) — schema registry
cms-panel.js (441 lines) — operator UI shell
content-admin.js (374 lines) — CRUD for content
navigator.js (337 lines) — region tree
editor-shell.js (316 lines) — editor frame
outline.js (298 lines) — page outline
context-menu.js (256 lines) — right-click menu
form-editor.js (249 lines) — form field editor
region-scanner.js (235 lines) — DOM scanner
visualizer.js (216 lines) — module preview
install-editor.js (184 lines) — first-run setup
region-editor.js (169 lines) — click-to-edit
selection.js (165 lines) — module selection
breadcrumb.js (147 lines) — path bar
query.js (126 lines) — queryable scope API
rerender-watcher.js (125 lines) — live updates
group-toggle.js (124 lines) — collapse/expand
store.js (120 lines) — state
scope.js (102 lines) — scoped queries
skin.js (98 lines) — skin loader
region-renderer.js (88 lines) — single region
inline-editor.js (87 lines) — text-edit-in-place
config-from-dom.js (73 lines) — bootstrap from existing HTML
content-api-client.js (67 lines) — PB API wrapper
load-annotation.js (39 lines) — annotation loader

6 app-fragments

editor-breadcrumb, editor-context-menu, editor-inspector, editor-navigator, editor-outline, editor-selection

1 detector + 1 annotator

detectors/elementor.js (Elementor HTML → annotation), scripts/annotate.js (scan dist + emit annotation.json)

2 skins (PENDING RENAME in P0.1)

reign.js → fresh-classic.js (sharp/serif/forest green). buddYx.js → fresh-soft.js (round/sans/blue). Both already have cssTokens + moduleDefaults, ready to use.

1Speed

This week

3 minutes from prompt to live, verified, with metrics. First two tasks: rename the proprietary skin names (P0.1) and decide the license (P0.2).

P0.1 (do first!) Rename skins: reign.js → fresh-classic.js, buddYx.js → fresh-soft.js. Update skins/index.js, all module skin: references, vendored copies in consumers, the panel skin picker, the manifest. Use git mv to preserve history.
P0.2 (DEFERRED, no push) License decision. The stub freshvibe-cms/LICENSE file says "License to be decided". Operator said "forget about P0 / license for now". Stub stays. No recommendation, no prompt, no deadline. Revisit when operator asks.
P1.1 Parallelize file generation in build_freshvibe_app (Promise.all). 5min → 1-2min.
P1.2 Auto-verify after build — GET /api/agent/verify?app=NAME curls the live URL, returns status + content checks
P1.3 Build metrics — wall time, token count, cost in the chat message
P1.4 Build cache — in-memory map intent-hash → files[], second build of same intent = free
P1.5 Build resumption — checkpoint after each file, resume from file N
P1.6 Stream preview — show each file as it's written (FileTree component)
P1.7 Spend tracking — capture Z.AI usage → PB spend_log collection → panel "Today's spend" card

2Editable

Weeks 2-3

Click a region, change text, see it update. Operator edits in the browser. VibeCoder's only job is to vendor freshvibe-cms/ into the app and wire the editor to PocketBase. All edit logic, UI shell, inspector, region-renderer, rerender-watcher already exist in the vendored Fv CMS.

P2.0 (do first in Phase 2) — Fv CMS update for VibeCoder's needs. The current Fv CMS was designed for static-exported sites (oscar-web). VibeCoder needs it to support PB-mutated annotations. ~3-5 small changes inside freshvibe-cms/, not bridge code. See Fv CMS updates needed section below.
P2.1 Wire FES Plan B Layer B (565 lines) — port to bridge, register /content-types/batch + /content-types/resolve endpoints
P2.2 Frontend spec-enrichment — batch fetch content types, inject schemas into LLM prompt
P2.3 Wire the 6 editor fragments + 30 runtime files into VibeCoder panel. editor-shell.js (316 lines) IS the panel. cms-panel.js (441 lines) IS the UI shell. region-editor.js (169 lines) IS click-to-edit. Just import and call.
P2.4 Edit-in-place — VibeCoder's contribution is TWO things: (a) when LLM builds an app, vendor freshvibe-cms/ into the app's directory (so the runtime ships with the app, not pulled from a CDN). (b) wire the editor's "save" to POST to PB instead of writing to the file. The Fv CMS already provides: inline-editor.js (87), region-renderer.js (88), rerender-watcher.js (125), editor-shell.js (316), cms-panel.js (441), region-editor.js (169), inspector (app-fragment). VibeCoder does NOT rebuild these — it just imports them and points them at PB.
P2.5 Plan validation — LLM plan must reference real field names. Use the existing content-types.js (632 lines, has the full schema registry).
P2.6 CRUD UI for content types — use the existing content-admin.js (374 lines) + content-api-client.js (67 lines). Just expose it in the panel.
P2.7 Region-to-content-type wiring at render time — annotation region: { contentRef: "BlogPost.list" } → use the existing query.js (126 lines) + content-api-client.js to fetch from PB

Recipe check (operator asked): All 30 runtime files in freshvibe-cms/runtime/ are reusable capabilities. They are NOT style recipes. The operator's "recipe" was right — these are the recipes. P2 is integration, not invention. Total new code in P2: ~200 lines of glue. The hard 6,000+ lines already exist.

Fv CMS updates needed (P2.0)

The Fv CMS currently assumes the annotation is the source of truth and the runtime renders from it. For VibeCoder's edit-in-place flow, three small things change:

PB-aware inspector fields — existing inspector handles text/select/color/number. New: a PB-record picker (for foreign keys), an image picker that uploads to PB storage, a URL picker that browses PB pages. Add as 3 new field types, drop into the existing field-type registry.
PB save adapter — currently the editor writes to the in-memory annotation. Add a save-to-pb(collection, recordId, annotation) adapter that the existing store.js calls when in "VibeCoder mode". ~30 lines.
Realtime channel — the existing rerender-watcher.js watches in-memory changes. Add a PB-SSE subscription so external edits (e.g. operator edits in one tab, sees it in another) re-render. ~40 lines.

These are Fv CMS PRs, not VibeCoder code. They live in freshvibe-cms/, get versioned, get vendored. Anyone using Fv CMS benefits. This is the doctrine: improve the shared CMS, every consumer benefits.

3Backend — adapter framework

Weeks 3-4

Operator picks the backend. LLM says "BlogPost", the right adapter (PB, Supabase, JSONBin, GitHub, Sheets, Notion, Cloudflare, IndexedDB, etc.) gets a real collection / record. No vendor lock-in — the adapter pattern means any backend works.

The 12+ backends the adapter framework supports

Backend	Cost	Auth	Realtime	Best for
PocketBase (own VPS)	Free	✅ built-in	✅ SSE	Full control, own data, no vendor
Supabase	Free tier (500MB DB, 50k MAU)	✅ built-in	✅ channels	Postgres power, want polish
Firebase	Free tier (1GB)	✅ built-in	✅ native	Google ecosystem, mobile-first
JSONBin.io	Free (10k req/mo)	❌ API key only	❌	Single JSON blob, no schema
npoint.io	Free	❌	❌	JSON bin with edit UI
Pantry	Free	❌	❌	JSON storage, simple
restdb.io	Free tier	✅ API key	❌	No-code DB with REST
GitHub Gist	Free (private OK)	PAT	via commits	Versioned data, git history = audit log
GitHub Issues	Free (private repo)	PAT	via webhook	Records as issues, fields as labels/comments
Google Sheets	Free (15GB Drive)	OAuth	via polling	Operator sees the data in real spreadsheet UX
Notion API	Free	OAuth	via polling	Operator edits in Notion, app reads
Airtable	Free tier (1.2k records)	PAT	via webhook	Spreadsheet power + REST
Cloudflare D1	Free (5GB)	API token	via DO	SQLite at the edge, fast global
Cloudflare KV	Free (100k reads/day)	API token	✅ native	Key-value, edge-cached
Cloudflare R2	Free (10GB, no egress)	API token	❌	File storage, S3-compatible
IndexedDB (browser)	Free	N/A	BroadcastChannel	Single-user, no server, data lives in browser
localStorage (browser)	Free	N/A	storage event	Personal tools, tiny data
OPFS (browser)	Free	N/A	❌	Real files in browser (images, PDFs)
PouchDB + sync	Free (local) + CouchDB for sync	varies	✅ changes feed	Local-first with optional sync

The adapter framework pieces

P3.0 Backend adapter framework — one interface { read, write, list, query, auth?, realtime? } in freshvibe-cms/runtime/adapters/. Each backend is one file, ~50-200 lines. Runtime picks based on annotation.backend.type.
P3.1 First adapter: PocketBase (because it ships with Fv CMS). Auto-create collections from annotation.contentTypes[].
P3.2 Second adapter: IndexedDB (because no server, no credentials, "just works" for personal tools). Default fallback.
P3.3 Third adapter: GitHub Gist (because git-history = audit log, matches FVW doctrine).
P3.4 Fourth adapter: Supabase (because operators ask for it).
P3.5 Fifth adapter: Google Sheets (because operator UX for non-technical users is unbeatable).
P3.6 Sixth adapter: Cloudflare D1 (because edge, fast, free).
P3.7 "Pick your backend" wizard on first run — annotation has backend.type: "?", runtime shows a card with all 12 options, each with "what you need to do" (sign up here, paste this key there). Operator picks, fills in 2-3 fields, app works.
P3.8 .env.example generated per-backend — operator sees exactly which keys to set
P3.9 Adapter capability matrix in the doc — "Supabase has realtime, JSONBin doesn't, IndexedDB has BroadcastChannel" — runtime degrades gracefully

No-VPS philosophy

Operator said "I will not make my VPS available to all users". Right. The adapter framework means VibeCoder builds apps that the end user connects to their own backend. The operator's VPS just hosts the static app. End user's data lives wherever they chose. Privacy by architecture, not by promise.

4Polish

Weeks 4-6

Apps LOOK good. Modules are enough. Operator feels in control. 17 modules already exist — P4.1 only adds what's actually missing, not duplicates.

P4.1 Module lib 17 → 30. Only add what's missing: form-field (date-picker, color-picker, rating, file-upload, select, checkbox, radio, textarea as sub-types), map, chart, audio, table, tabs, modal, search, social-share, gallery, slideshow, callout, comparison, stats, embed. Skip any of the 17 existing types — they ship already.
P4.2 Skins 2 → 6. fresh-classic + fresh-soft (already exist post-rename) + add: fresh-modern-dark, fresh-pastel, fresh-newspaper, fresh-brutalist. All work with the same skin.js loader (98 lines, already exists).
P4.3 Module-level validation at write time — reject out-of-palette colors. Use the existing skin.cssTokens to know the palette.
P4.4 Region size budget — warn at 30 modules, block at 50. Use region-scanner.js (235 lines, already exists) to count.
P4.5 Security defaults — _headers (CSP, X-Frame-Options), _env.example, SECURITY.md, RATE_LIMIT.md
P4.6 Style presets — annotation declares skin: "fresh-modern-dark", every module inherits the right tokens via the existing skin.js loader. No new code — just make it pickable in the panel.
P4.7 Module picker — operator adds a module to a region without re-running the build. Uses the existing modules/index.js registry.

5Operational

Weeks 6-8

Operator can run a fleet of apps without babysitting.

P5.1 One-click deploy — panel button → bridge → live
P5.2 Auto-verify on every deploy + periodic heartbeat (alert if any app 5xx or 404)
P5.3 Versioned runtime — annotation declares fvwRuntimeVersion, runtime enforces
P5.4 Bridge health check — systemd service, /healthz, panel shows status
P5.5 Rate limit — operator configures per-day LLM token budget
P5.6 Spend tracking dashboard — daily, weekly, monthly, per-app
P5.7 Error log on bridge — every failed LLM call logged with context, queryable in panel

6Ecosystem

Weeks 8-12

Operator can scale from one app to ten. The product is a platform.

P6.1 Git-as-deploy — every successful build → commit, every app has git remote, rollback
P6.2 Template gallery — operator's apps can be cloned as templates, list in panel
P6.3 Multi-stack doctrine — FVW for Android (Kotlin + Compose), Windows (WinUI 3), CLI (Python). Same doctrine, different stack. Phase 6 = written doctrine, not code.
P6.4 Staging subdomains — wales-blog-staging.freshvibeapps.com per app, promote-to-prod button
P6.5 Performance budgets — file size cap, region size cap, annotation size cap, warn at 80%, block at 100%
P6.6 App heartbeat / error reporting — apps POST to bridge on errors, panel shows health
P6.7 Multi-tenant isolation — multiple VPS users, each with their own apps
P6.8 Annotation clone — "use this app as a starting point" button in panel
P6.9 Public FVW v8 spec — annotation schema as .schema.json with docs, hosted at fvw.freshvibeapps.com

7FVS — wait and see

Wait and see, future direction pending

The FVS Pact at pact/workspaces/vibecoder/workspace.md defined a sovereign workspace with 7 chips and 5 layouts. That was a hypothesis, not a destination. What we build here is the empirical data. If FVS happens, it inherits from here — not the other way around. The chips, layouts, chrome, may all be different as a result of what we do. We don't pre-commit.

What the FVS CentreStage canon actually says (the "S1-S2-S3 / home surface" pattern)

4 surfaces: S1 (left) / S2 (centre, always-on, the home surface) / S3 (right, often delegated to Peek in Studio mode) / S4 (bottom, 3over1 only)
5 arrangements: 1col (S2 only) / 2col (S1+S2) / 3col (S1+S2+S3) / stacked (S2 expanded, chips 2/3/4 stack inside S2) / 3over1 (S1+S2+S3 on top + S4 underneath)
Chip-surface switch rule: 1 chip → S2, 2 chips → S1+S2, 3 chips → S1+S2+S3, 4 chips → depends on layout
Curtains: never move chips, never resize S1 or S3, S2 is the only surface that expands
Backstage is the S3 right rail. Peek is a card inside Backstage. Inside Studio, S3 is delegated to the chrome's Backstage (containing the Peek card). VibeCoder's S3 panel goes dormant, settings move to Backstage/Peek
Peek shows ONE adaptive card per active chip. Coder → AST/State/Logs, Cinema → Inspector/Hierarchy, etc. "Peek's structure cannot be modified" (constitutional)
Cockpit ownership (the "S3 dormant" pattern): inside FVS Studio, the workspace owns S1+S2, the chrome owns S3+S4. Outside FVS Studio (VibeCoder-standalone), the workspace owns all 4 surfaces. So S3 is alive in standalone mode, dormant in Studio mode (delegated to Peek)
Onboarding (Origin workspace pattern): "no timeline, no inspector, no dev tools" — curated surface for first-launch. Origin owns S1+S2 inside Studio, all 4 outside

From workspace.md: "VibeCoder is a peer to VibeScope, not a sub-workspace of it." That peer relationship is a useful idea. The chip grammar and layouts are not pre-committed. They may inform what we do in the S3 panel, they may not.

What we have today (no FVS chrome, no pre-commitment)

VibeCoder-standalone — the web app at preview.mockups.freshvibeapps.com/vibechat/. This is the "VibeCoder-as-Origin" form: owns all 4 surfaces outside Studio. vc-s1 (left), vc-s2 (centre / chat / home surface), vc-s3 (right / settings), vc-s4 unused. S3 is alive here
S3 panel — the side surface with settings / users / backups / services / etc. The chip system could apply here, but doesn't have to. Stage 1B desktop UX is a reference, not a requirement
If VibeCoder ever docks in FVS Studio: vc-s3 goes dormant (chrome owns S3, Backstage containing Peek takes over). Settings move to Backstage's Peek card. vc-s1 + vc-s2 stay (the workspace's S1+S2). Same code, conditional rendering based on whether the FVS Studio chrome is detected
What we build here generates the patterns. If FVS happens, it inherits. If FVS doesn't happen, we still have VibeCoder-standalone working

What to incorporate now from the FVS pattern (selectively)

P7.1 (in the plan, ~2-3 days work) Chip system in the Backstage panel — settings / users / backups / services as navigable chips instead of stacked sections. Concrete work item, not just a hypothesis. Reference: the FVS chip grammar (7 chips, but only the "settings/admin" subset applies — Coder, Blueprint, Flow). If VibeCoder-standalone ever docks in FVS Studio, this code goes dormant — settings move to Backstage's Peek card. Same code, conditional rendering.
P7.2 (later, only if useful) Other bits from FVS that make sense to incorporate: dock-on-left if the panel grows, command palette if operators have many actions, the 5 layouts if we ever have multi-workspace view. None of these are commitments — they happen if they help, not because the Pact says so

What we are NOT doing

NOT pre-committing to the 7 chips as the destination. They may inform; they don't rule
NOT building the 5 layouts unless they help the home surface. The home surface is VibeChat, not a chip of a multi-workspace view
NOT building FVS Studio shell as a future commitment. If it happens, it happens because we want it, not because the Pact ordained it
NOT building Tauri wrap unless operator decides the desktop experience is worth the maintenance burden. The web app works fine

The right framing now: VibeCoder-standalone is "VibeCoder-as-Origin" — owns all 4 surfaces outside the Studio chrome. S2 is the home surface (VibeChat). S3 is alive in this form. If it ever docks in Studio, S3 goes dormant (chrome owns S3, Backstage shows the contextual lens via the Peek card). What we build here is what FVS would inherit, if FVS gets built. Not the other way around. The Pact is a reference, not a target. We pick and choose what works best from a VibeCoder perspective, then later integrate as a home surface.

What ships when

Now

All 9 foundation features live and verified

Week 1

3-minute builds with verify + metrics + cache + stream preview + spend tracking

Weeks 2-3

Edit-in-place + CRUD UI + plan validation + content-type wiring

Weeks 3-4

Real backend with auto-created PB collections, sample data, RLS by default

Weeks 4-6

30 modules, 6 skins, security defaults, style presets, module picker

Weeks 6-8

One-click deploy, versioned runtime, rate limit, spend dashboard, error log

Weeks 8-12

Git-deploy, template gallery, multi-stack doctrine, staging, monitoring, public spec

After

FVS — wait and see. Chip system in S3 panel (now). Other FVS patterns (only if they help). No pre-commitment.

12 weeks to a deep product. Phase 7 = what we build here informs FVS, not the other way around.

Concrete "do this week" list

Day 1 (morning) — Rename skins (P0.1) + decide license (P0.2)

P0.1 RENAMEIn freshvibe-cms/skins/: git mv reign.js fresh-classic.js, git mv buddYx.js fresh-soft.js. Update internal id: and label: fields inside each file.
P0.1 INDEXUpdate freshvibe-cms/skins/index.js exports to point at the new filenames.
P0.1 GREPFind every reference to reign or buddYx in freshvibe-cms/, vendored copies, and the VibeCoder panel. Update all to fresh-classic / fresh-soft. Use the bridge's "rename across all consumers" pattern if it has one, else manual grep + sftp edit.
P0.1 DEPLOYRe-vendor freshvibe-cms/ to the panel. Commit, push, deploy.
P0.1 TESTBuild a wales-blog, confirm it still uses fresh-classic as default skin. Old "reign" references return 404 from get_freshvibe_pattern.
P0.2 LICENSEPick the license for freshvibe-cms. Options: MIT / Apache 2.0 / GPL / AGPL / BSL / Polyform / proprietary / dual. Operator's call — no recommendation, no rush. Until decided, the stub LICENSE file (in freshvibe-cms/) says "License to be decided" and the code is effectively all-rights-reserved.
P0.2 APPLYReplace the stub LICENSE with the real license text. Add SPDX-License-Identifier headers to all source files. Update README.

Day 1 (afternoon) — Parallel build + verify

P1.1Parallelize build_freshvibe_app (Promise.all(files.map(generateOne))) — 5 lines, 30 min
P1.2Add GET /api/agent/verify?app=NAME to bridge — ~40 lines, 1 hour
P1.3Build metrics in chat message — ~20 lines, 30 min
P1.4Build cache in-memory — ~40 lines, 1 hour
TESTBuild wales-blog, verify <2 min with metrics

Day 2 — Resumption + streaming + spend

P1.5Build resumption (checkpoint per file) — ~60 lines, 2 hours
P1.6FileTree component (stream preview) — ~80 lines, 2 hours
P1.7Spend tracking (bridge + PB spend_log) — ~100 lines, 3 hours
TESTBuild, kill at file 3, resume, verify

Day 3 — Wire FES Plan B Layer B

P2.1Port 565 lines from fes-plan-b-layer-b-output.md to bridge — 4 hours
P2.2spec-enrichment.ts batch fetch + intent resolve — ~60 lines, 2 hours
TEST"Build a real estate listing app" — LLM uses Listing fields by name

Day 4-5 — Editor + CRUD

P2.3Wire 6 editor fragments into panel — 4 hours
P2.4Edit-in-place (the hard one) — 6-8 hours
P2.5Plan validation — ~40 lines, 1 hour
P2.6CRUD UI — 4 hours

Day 6-7 — Backend + samples

P2.7Region-to-content-type wiring at render — 3 hours
P3.1Auto-create PB collections — ~100 lines, 3 hours
P3.2Intent resolver upgrade — 2 hours
P3.3Sample data seeder — ~60 lines, 2 hours
TESTBuild a real estate app, see collection in PB, see 3 sample listings, click one, edit in browser, page updates

Decisions locked (unless you object)

Architecture decisions

D-2026-07-28-160 — Module gap is 13, not 18. Existing 17 already cover: accordion, breadcrumb, button, carousel, contact-form, cta, cta-box, heading, icon-list, image, info-box, menu, paragraph, social-icons, testimonial, video. New: form-field (with date-picker/color-picker/rating/file-upload/select/checkbox/radio/textarea), map, chart, audio, table, tabs, modal, search, social-share, gallery, slideshow, callout, comparison, stats, embed.

D-2026-07-28-167 (operator directive 2026-07-28) — Rename proprietary skin names: reign → fresh-classic, buddYx → fresh-soft. All consumers (vendored copies) re-vendored. Panel skin picker updated. Manifest updated. P0.1 in Phase 1.

D-2026-07-28-168 — 4 new skins (fresh-modern-dark, fresh-pastel, fresh-newspaper, fresh-brutalist) added to fresh-classic + fresh-soft = 6 total. All use the existing skin.js loader.

D-2026-07-28-169 — "Recipes" = reusable runtime capabilities, not styles. The 30 files in freshvibe-cms/runtime/ ARE the recipes. P2 is integration, not invention. Never duplicate a runtime file by rebuilding the same logic in the bridge or the panel.

D-2026-07-28-163 — Security defaults = CSP header, env.example, SECURITY.md, RATE_LIMIT.md. NOT full "secure by default" (no auto-RLS for new PB collections). That's a future "secure mode" toggle.

D-2026-07-28-164 — Multi-stack is doctrine research, not code, in Phase 6. We won't build Android apps in 12 weeks. We WILL have a written doctrine with patterns. Phase 7+ implements.

D-2026-07-28-170 (operator directive 2026-07-29) — VibeCoder is the FVS Pact's web-first execution layer, not a separate product. The FVS Pact v6/v7/v8 (the modules-and-tiers, the FVW method, the smart-app doctrine) is the doctrine VibeCoder implements. Drawing a "module builder vs app builder" line was wrong. The 17 modules, 30 runtime files, 2 skins in freshvibe-cms/ are FVS's runtime, not new. The novelty is the LLM interface + 18-backend adapter framework. Roadmap framing updated.

D-2026-07-28-171 (operator directive 2026-07-29) — License: TO BE DECIDED. Operator explicitly said "I'm definitely not deciding on a license right now". A stub LICENSE file exists in freshvibe-cms/ that says "License to be decided". P0.2 in Phase 0 is the placeholder. Until decided, all rights reserved by default. No "MIT-style" claims anywhere — that was a previous-session hallucination I corrected in the Q&A.

D-2026-07-28-172 (operator confirmations 2026-07-29) — Three corrections on the FVS CentreStage canon, all locked:

1. S3 dormant framing is correct. VibeCoder's vc-s3 goes dormant when docked in FVS Studio. Chrome owns S3 in that mode.

2. Peek is now Backstage containing a Peek card. Per Panel Surface Rename Amendment 2026-07-01, what was "peek" became "backstage" and Peek is now a card inside Backstage. Not a separate surface. When S3 is delegated in Studio mode, the chrome's Backstage panel takes over, with Peek card showing the contextual lens.

3. Home surface flexibility — left undecided. S2 is the default home surface but not required. The framework should be flexible. Operator didn't want to lock it in.

Latest operator directives (2026-07-29 00:44)

D-2026-07-28-173 (operator directive 2026-07-29) — Three directives, all locked:

1. "in your plans" — chip system in the Backstage panel (P7.1) goes into the plans as a concrete work item, not just a hypothesis. ~2-3 days of work. Add file path, spec, acceptance criteria.

2. "forget about P0 / license for now" — license decision deferred. The stub freshvibe-cms/LICENSE stays. No push, no recommendation, no deadline. Revisit when operator asks.

3. "let's leave it at that for now pending future direction" — Phase 7 stays "wait and see". FVS direction comes later, not now. No pre-commitment to the chips/layouts/chrome. What we build here is the empirical data FVS would inherit.

What I want feedback on

License decision (P0.2) — operator said "not deciding on a license right now". The stub LICENSE file is in place. Is there a category to narrow it to (permissive, copyleft, hybrid, proprietary)? Or keep the stub indefinitely?
FVS Pact framing — I drew a line between "FVS as module builder" and "VibeCoder as app builder" that wasn't there. The right framing is "VibeCoder is FVS's web execution layer". The 17 modules + 30 runtime files are FVS's runtime, not new. Is the reframing right? Should I do a deeper audit: "which FVS Pact features are not yet implemented in VibeCoder"?
Phase 7 = wait and see — operator said "what we have here is simply a standalone, what we build here will be what is in fvs not the other way around. we may end up there but not yet this is evolving a little differently so we wait and see about Fvs. fvs chrome chips etc may be different. as a result of what we do here. but you could use the chip system here in the S3 panel and there may be other bits it makes sense to already incorporate here. what we have here is like the home surface in centre stage. it might not use chip navs in the home surface does that make sense." The chips and layouts are a hypothesis, not pre-committed. The home surface (VibeChat) doesn't have to use them. The Backstage panel could use the chip pattern (P7.1, in the plan). Phase 7 in the roadmap is now "wait and see, future direction pending" — FVS will inherit from what we build, not the other way around. My take: P7.1 (now) = chip system in S3 panel as a low-effort experiment. P7.2 (later) = see what works in S3, then decide if home surface wants chips. Your call on the priority and the experiment.
Module list — 13 new modules (form-field, map, chart, audio, table, tabs, modal, search, social-share, gallery, slideshow, callout, comparison, stats, embed) on top of 17 existing. Did I miss any?
Skin names — fresh-classic and fresh-soft for the renamed skins. Better names? Or keep the old names private (just a) and add new public ones?
Skin list — 4 new skins. Did I miss a look you want?
Recipe use — operator said "I thought you had some reusable abilities already". Yes — 30 runtime files. P2 is integration. Is the framing right? Do you want me to audit each runtime file and map which panel/bridge feature uses which?
Timeline — 12 weeks to a "perfect" product. OK? Or skip Phase 4-6 polish and go straight to multi-stack?
Edit-in-place architecture — I'm assuming inline-editor.js + region-renderer.js + rerender-watcher.js can drive it. Confirm? Or do we need iframe + postMessage?
"Perfect product" extras — does it include: a) native mobile app for VibeCoder? b) a real product name (not "VibeCoder")? c) public launch (landing, docs, video demo)? Those are Phase 7+ items I didn't include.