FWV v8 — FreshVibe Way
The app-agnostic doctrine stream. Helps any app align with FVS patterns. Does not turn non-FVS apps into FVS.
Acronym
"FreshVibe Way" — first letter of each word = FVW.
A historical typo: the local workspace has /workspace/FWV-v8/ (FWV instead of FVW). The canonical path in avidtech6/freshvibestudio is pact/freshvibe-way-v8/. Use the canonical path; treat the local typo directory as deprecated.
What FWV v8 is
A 29+ section doctrine that any app can use to align with FVS patterns. It covers:
- §00-01 — philosophy, app constitution
- §02 — folder layout (§02 is the canonical FVW file structure)
- §03-04 — DNA format, trace-atlas schema
- §05-06 — recipe (a single refactor recipe), refactor procedure
- §07-08 — execution model, anti-drift
- §10-12 — modules-as-clusters, recipe-book, mirrors-and-forks
- §13-15 — shadows, tweaks, micro-models
- §16-18 — smart-app-product, modules-and-tiers, revibe-pattern
- §19-21 — recipe-extraction, semantic-visual-intent, mit-boundary-doctrine
- §22-23 — behaviour-first-codex, two-view-substrate
- §24-26 — vibe-chat-doctrine, document-composition-materialisation, revibe-lifecycle
- §27-29 — drift-discovery-protocol, side-protocol-pattern, test-case-scaffolding
- §3 — file-model-doctrine
(§09 was retracted; numbers skip to maintain stability.)
App-agnostic invariant (post-contamination-fix)
Per 8c093ef on 2026-06-22 18:37 UTC, the doctrine was scrubbed of FVS-specific names in generic examples:
| Old | New |
|---|---|
| VibeCoder | Workspace A |
| VibeScope | Workspace B |
| Origin | Workspace C (in tier examples only; historical-comment meaning preserved in §18) |
| FreshCards | Sample App |
| FreshVibe Studio | Sample App |
24 files, 169 swaps. Before this fix, an AI reading only the FVW v8 repo with no FVS context would treat these as doctrine rules, leading to refactor plans that proposed FVS workspace partitioning for non-FVS apps. The fix removes that trap.
A non-FVS app has zero business knowing about FVS workspaces. If a non-FVS module ever needs to become an FVS workspace, that's an explicit ask to FVS Mavis later — not something a refactor plan pre-decides.
Where FVS names are appropriate
- FreshVibe Refactor Contract HYBRID mode (FvS-specific)
- FreshVibe Runtime Subsystem Catalogue (audits FVS's own capabilities)
- Master Plan (FvS-specific build target)
Where FVS names are NOT appropriate
- Recipe Book schema (must be app-agnostic)
- Generic examples in doctrine docs
- AST walker source code
- Clean-room check logic
The plan-correction addendum
studio/.fvs/plans/2026-06-22-disciple-connect-plan-correction.md is a new constitutional artifact. Any FVW v8 alignment plan for a non-FVS app must reference it. The addendum:
- Drops B1 (workspace partitioning is FVS-specific)
- Defaults B2-B5 (Vite build, full recipe books, App Mode, fix-bugs-as-you-go)
- Adds §6 identity contract (what stays the app's own vs what the FVW v8 alignment adds)
§30 hard cap (FWV v8 invariant)
Per memory: "§30 hard cap 200L/.tsx" — any single .tsx file in an FVW v8-aligned app should be ≤200 lines. docHub is markdown, not .tsx, but the spirit applies: keep files focused, split when needed.
§00.2 reconstructability invariant
Per memory: "§00.2 reconstructability invariant holds." — the doctrine must be reconstructable from the recipe book + trace atlas + codex. No external hidden state.
Cross-references
doctrine/governance.md— the two-layer model (FVS-Pact + FWV v8)decisions/D-062— the contamination fix at8c093efmemory/freshvibe-way-v8/...— session reports on FWV v8 workpact/freshvibe-way-v8/00-philosophy.md— the source of truth