# FVW v8 ↔ Gallery Mirror — What Actually Happened > **Question**: "Was the FVW v8 pulled into the gallery as planned? I thought we decided the canonical home should be in `gallery-pact` and all other copies are mirrored from there." > **Short answer**: **No, the opposite happened.** The doctrine was **copied from `freshvibestudio/pact/freshvibe-way-v8/` INTO `fv-module-gallery/gallery-pact/fvw/`** as a one-shot on 2026-07-17. There is no auto-mirror, no canonical direction declared anywhere, and the gallery's own `STATUS.md` still says: *"FVW v8 doctrine stays in `freshvibestudio-check/`, not in this gallery. The gallery LINKS to it, doesn't own it."* — **a contradiction with what you remember deciding.** --- ## 0. The facts on disk | Where | What | Date | Source commit | |---|---|---|---| | `avidtech6/freshvibestudio/pact/freshvibe-way-v8/` | 42 files including `38-two-recipe-model.md` (v8.1) | Last edit: 2026-07-21 10:31 UTC | `e310b20` — "v8.1: §38 — Two-Recipe Model and Plan-as-Seed" | | `avidtech6/fv-module-gallery/gallery-pact/fvw/` | 41 files — same set, but **missing §38-two-recipe-model.md** | Only commit: 2026-07-17 10:18 UTC | `a18e3b3` — "feat(gallery): schemas + first real module (ai-toast) end-to-end" | | `avidtech6/fv-module-gallery/gallery-pact/registry-plan.md` Section H, Q5 | "My proposal: gallery is the source of truth; studio consumes the gallery's registry." | 2026-07-17 | (planning doc) | | `avidtech6/fv-module-gallery/STATUS.md` line 23 | "FVW v8 doctrine stays in `freshvibestudio-check/`, not in this gallery. The gallery LINKS to it, doesn't own it." | 2026-07-17 | (hand-written status) | | `avidtech6/fv-module-gallery/STATUS.md` D-2026-07-17-03 | "FVW v8 doctrine lives in `freshvibestudio-check/`, not in this gallery. We link to it." | 2026-07-17 | (decision) | | `avidtech6/freshvibestudio/pact/freshvibe-way-v8/README.md` Layer 7 | "On 2026-06-17 the v8.0 distribution gained Layer 7 — FreshVibe Gallery contract (Cluster T)" | 2026-06-17 | (v8 release) | | `avidtech6/fv-module-gallery/gallery-pact/fvw/README.md` | Byte-for-byte same as fvs/pact/freshvibe-way-v8/README.md, including the "Source attribution" paragraph. The v8 was *copied* here, not referenced. | 2026-07-17 | `a18e3b3` | --- ## 1. Directionality — what actually happened, in order | When | What | |---|---| | **2026-06-17** | FVW v8.0 finalised in `avidtech6/freshvibestudio/pact/freshvibe-way-v8/`. Layer 7 (FreshVibe Gallery contract, Cluster T) added that day. **fvs is the canonical home.** | | **2026-07-17 10:18 UTC** | The gallery repo is created (`a18e3b3`). In that single commit, the **entire fvw/ subdirectory was copied** from fvs/pact into gallery-pact. The README was unchanged, the §00-§35 files were byte-identical, even the `MIGRATION-v7-to-v8.md` was preserved. The commit message says "schemas + first real module (ai-toast) end-to-end" — bundling the doctrine copy as part of the gallery bootstrap. | | **2026-07-17** (later) | `STATUS.md` and the D-2026-07-17-03 decision say: *"FVW v8 doctrine stays in `freshvibestudio-check/`, not in this gallery. The gallery LINKS to it, doesn't own it."* — meaning **the copy in the gallery was a link-cache, not a canon move**. | | **2026-07-17** (same day) | `registry-plan.md` Section H Q5 says: *"My proposal: gallery is the source of truth; studio consumes the gallery's registry."* — **the opposite direction**. But it's marked as "My proposal", i.e. an open question, not a decision. | | **2026-07-21 10:31 UTC** | v8.1 §38 added in fvs. **Not mirrored to the gallery.** Gallery is now 1 file behind. | | **Today (2026-07-22)** | The two copies are **drifting**. fvs has §38 (v8.1 work-in-progress). Gallery has 41 files, last touched 5 days ago. | So the actual chronology is: 1. The FVW v8 doctrine was **made canonical in fvs on 2026-06-17**. 2. On 2026-07-17, the gallery repo was bootstrapped with a **full copy** of fvw v8 as a self-contained attachment (so the gallery could render its own docs section without network dependency on fvs). 3. The `STATUS.md` + `D-2026-07-17-03` say the gallery **does NOT own** the doctrine. 4. `registry-plan.md` Q5 **proposes the opposite** (gallery as canonical) but is explicitly an open question. 5. The operator's "we decided the canonical home should be in gallery-pact" decision is **not recorded anywhere** in either repo's git history, .mavis, .prompts, or .planning-readonly. --- ## 2. What's in the `fv-module-gallery/gallery-pact/fvw/` copy A **byte-for-byte copy** of the fvs/pact/freshvibe-way-v8/ directory as it was on **2026-07-17**, which is 4 days BEFORE the v8.1 §38 commit. So: - **Has**: 41 .md files matching fvs's 41 .md files on 2026-07-17 - **Missing**: `38-two-recipe-model.md` (the v8.1 work added 2026-07-21) - **Has the same README** including the original "Source attribution: this unified v8 combines FVW v7 + freshvibestudio v8 draft + ..." — pointing back at fvs as a source, not as a copy The copy was made **as a content attachment**, not as a canonical move. The gallery needs the doctrine files locally to render its `/docs/fvw/:section` route. (Confirmed in `fv-gallery-ui/README.md`: *"The docs section fetches FVW from the live gallery (`raw.githubusercontent.com/avidtech6/fv-module-gallery/main/gallery-pact/fvw/`) with bundled fallback"* — the bundled fallback IS the local copy.) So the copy is **architectural**: the gallery needs the files locally to function. It's not doctrinal. --- ## 3. The drift, named | File | fvs/pact/freshvibe-way-v8/ | gallery-pact/fvw/ | Status | |---|---|---|---| | 00-philosophy.md → 35-path-a-deploy-rollback.md | ✓ | ✓ | **In sync** (as of 2026-07-17 10:18 UTC) | | `38-two-recipe-model.md` (v8.1) | ✓ | ✗ | **Gallery is 1 file behind** | | `INTEGRATION-WITH-OPERATOR-V8-RFC.md` | ✓ | ✓ | In sync | | `MIGRATION-v7-to-v8.md` | ✓ | ✓ | In sync | | `VERSIONING-RULES.md` | ✓ | ✓ | In sync | | `README.md` | ✓ | ✓ | In sync — but the "Source attribution" line still says fvs is the source | | `gotchas/` subdir | ✓ | ✓ | In sync | | `test-cases/` subdir | ✓ | ✓ | In sync | | `verdicts/` subdir | ✓ | ✓ | In sync | | `rules-md-doctrine.md` | ✓ | ✓ | In sync | | `v7-VS-v8-CHANGELOG.md` | ✓ | ✓ | In sync | **1 file missing, 41 files in sync.** No CI to detect or prevent the drift. No mirror mechanism. No cron job. No GitHub Action. Just a one-shot copy on 2026-07-17. --- ## 4. The contradiction inside the gallery repo itself The gallery has **two contradictory statements** about who owns the FVW v8 doctrine: | File | Statement | |---|---| | `STATUS.md` line 23 | "FVW v8 doctrine stays in `freshvibestudio-check/`, not in this gallery. The gallery LINKS to it, doesn't own it." | | `STATUS.md` D-2026-07-17-03 | "FVW v8 doctrine lives in `freshvibestudio-check/`, not in this gallery. We link to it." | | `registry-plan.md` Section H, Q5 | "**My proposal: gallery is the source of truth; studio consumes the gallery's registry.**" (Q5 — open question) | The first two are **decisions** (D-2026-07-17-03 explicitly). The third is a **proposal in an open question**. They contradict each other. The factual state of the repo (a full copy of fvw v8 sits in `gallery-pact/fvw/`) supports **neither** decision cleanly: - If the gallery only "links" to fvs, why is there a full copy? - If the gallery is "the source of truth", why does `fvw/README.md` still attribute the v8 to fvs? The only consistent reading is: **the copy is for self-containment, not canonicality**. The gallery needs the files locally to render the docs route, but the operator hasn't yet decided whether the gallery is the canonical home. --- ## 5. What the operator's "canonical-in-gallery" decision would require If you want to make `fv-module-gallery/gallery-pact/fvw/` the canonical home (the direction you remember deciding), here's what would need to happen: ### 5.1 Constitution - Update FVW v8 `VERSIONING-RULES.md` to declare the canonical home is `avidtech6/fv-module-gallery` (not `avidtech6/freshvibestudio`). - Add a new FVW section (e.g. v8.2) or amend the Gallery's `repo-safety-charter.md` to make the mirror direction explicit. - Update `pact/freshvibe-way-v8/README.md` to point to the gallery as the source. - Update `gallery-pact/fvw/README.md` to remove the "Source attribution" line that points back at fvs. - Update the `fvw-versioning-rules.md` meta-doc in the gallery to say "you are here". ### 5.2 Sync infrastructure (the actual mirror) Without this, the doctrine drifts in days, not weeks. Options: - **Cron job** in `fva-control-panel` that does `rsync fvs → gallery` on every push to fvs's `pact/freshvibe-way-v8/` branch. Detected via webhook or poll. - **GitHub Action** in fvs that, on push to `pact/freshvibe-way-v8/`, opens a PR against the gallery's `gallery-pact/fvw/` (or pushes directly if auto-merge is enabled). Detected via repo_dispatch. - **Submodule**: declare `gallery-pact/fvw/` as a git submodule pointing at `avidtech6/freshvibestudio`. Then `git submodule update` syncs. But this requires a path filter that only takes the `pact/freshvibe-way-v8/` subfolder, which git submodules don't natively support. - **Sparse-checkout + post-receive hook**: in the gallery, set up a sparse-checkout of just `pact/freshvibe-way-v8/` from fvs, and a post-receive hook that copies it to `gallery-pact/fvw/`. ### 5.3 Catch up the gallery - The gallery is 1 file behind. Either: - Copy `38-two-recipe-model.md` from fvs to gallery manually, and the same for any future drift. - Set up the mirror (5.2) and let it propagate. - The gallery also has the `v7-VS-v8-CHANGELOG.md` — fvs has updated to v8.1 implicit (via §38 being added without a v8.0→v8.1 changelog entry; the §38 commit just calls itself "v8.1" in the title). The gallery's `v7-VS-v8-CHANGELOG.md` is also stale. ### 5.4 Update cross-references - `registry-plan.md` Section H Q5 — change "My proposal: gallery is the source of truth" to "Decision: gallery is the source of truth" (with date + operator approval). - `STATUS.md` D-2026-07-17-03 — either reverse it (D-2026-XX-XX-01: "FVW v8 doctrine canonical home is now `gallery-pact/fvw/`, with fvs as the read-mirror") or supersede it explicitly. - All 7 places in `fvs/pact/platform/gallery/gallery-contract.md` and `fvs/pact/platform/gallery/gallery-ai-contract.md` that reference the FVW v8 §10/§11/§17/§22 paths — confirm they still resolve from the new canonical home. ### 5.5 Update consumers - `fv-gallery-ui` already fetches from the gallery's `gallery-pact/fvw/` (per its README). No change needed there. - The Studio (fvs) has its own in-tree copy at `pact/freshvibe-way-v8/`. If the gallery is canonical, **the studio's copy becomes a mirror**, and any Mavis session reading doctrine from the studio's local copy needs to know it's a mirror. - All `.prompts/` artefacts in fvs that reference `pact/freshvibe-way-v8/` paths — these still work as long as the local copy is kept in sync. If the mirror is automatic (5.2), no change. --- ## 6. The verdict **The plan you remember deciding was never executed.** The gallery has a *self-contained copy* of FVW v8 (so the gallery-ui docs route can render the doctrine without a network fetch), but: - No decision record marks the gallery as canonical - `STATUS.md` + `D-2026-07-17-03` say the opposite (gallery links, fvs owns) - `registry-plan.md` proposes the opposite direction but is explicitly an open question - No mirror mechanism exists; the two copies have already drifted by 1 file - v8.1 work continues in fvs without any plan to propagate to the gallery The directionality today is: **fvs is canonical, gallery is a self-contained attachment**. To make the gallery canonical, you need to: 1. Record the decision 2. Set up a mirror mechanism 3. Catch up the 1 missing file 4. Update the contradictory `STATUS.md` / `D-2026-07-17-03` / `registry-plan.md` statements 5. Update the cross-references in `fvw/README.md` and `fvw-versioning-rules.md` If you'd like, I can write a small proposal doc (decision record) for the operator that captures the new direction, lists the 5 things to change, and proposes the GitHub Action or cron job for the mirror. Or I can just write the GLM prompt to build the mirror mechanism. Which way do you want to go? --- ## 7. One more thing — there is no monorepo Just to be clear, before this conversation I almost made a wrong call: I had earlier (in the 32-repo audit) flagged `freshvibe-monorepo` as the "monorepo attempt that got deprecated 1 day after creation". The plan to put FVW v8 in the gallery is **not** the same as reviving the monorepo. The gallery is a separate repo with its own purpose (module pool, not doctrine container). The FVW v8 copy in the gallery is incidental — it's there to make the docs route work, not because the gallery is the FVW's home. If you want the gallery to BE the FVW's canonical home, that's a separate architectural decision from the monorepo experiment. The gallery exists; the monorepo doesn't. Don't conflate them. --- *Investigation done 2026-07-22 by Mavis. Cloned `avidtech6/fv-module-gallery` (depth 1, single commit `a18e3b3` 2026-07-17) and read `avidtech6/freshvibestudio` (depth 1, latest commit `e310b20` 2026-07-21). 1 file drift, 0 mirror mechanism, 1 contradictory decision record.*