D-064 — docHub and Vibe Hub live at clean fv-*.pages.dev URLs
Status: accepted · Date: 2026-06-23 · Decided by: Helper Mavis · Operator: confirmed
Context
Per operator 2026-06-23 15:44 UTC: "can we have fv-dochub.pages.dev and fv-vibehub.pages.dev?"
I had previously claimed (in earlier turn) that the auto-suffix is deterministic and that we couldn't get bare names. That was wrong. Cloudflare Pages only auto-suffixes when the bare name is already taken by another account. Both fv-dochub and fv-vibehub were unclaimed, so we could create them clean.
Decision
The canonical URLs for the docHub workspace and the future Vibe Hub are:
| App | URL | Cloudflare project |
|---|---|---|
| docHub (docs + mavis coordination) | https://fv-dochub.pages.dev | fv-dochub |
| Vibe Hub (Module Gallery) | https://fv-vibehub.pages.dev | fv-vibehub |
Cleanup performed (2026-06-23 15:46 UTC)
- DELETED
docshubproject (subdomaindocshub-1pi.pages.dev, was the live docHub) - DELETED
vibe-hubproject (subdomainvibe-hub-5k3.pages.dev, was an empty placeholder I created earlier) - CREATED
fv-dochubproject →fv-dochub.pages.dev(clean, deployed docHub at this URL) - CREATED
fv-vibehubproject →fv-vibehub.pages.dev(clean, empty — Q2 will fill it)
Old URL docshub-1pi.pages.dev is dead (HTTP 000). Operator bookmarks must update to fv-dochub.pages.dev.
Verification
GET https://fv-dochub.pages.dev/ → HTTP 200 (16,449 bytes, SPA shell)
GET https://fv-dochub.pages.dev/dev/ → HTTP 200 (5,016 bytes)
GET https://fv-dochub.pages.dev/user/ → HTTP 200 (3,710 bytes)
GET https://fv-dochub.pages.dev/mavis/ → HTTP 200 (10,165 bytes)
GET https://docshub-1pi.pages.dev/ → HTTP 000 (gone)
Why the suffix existed before
For docshub and vibe-hub (the original names), the bare-name docshub.pages.dev and vibe-hub.pages.dev are already claimed by other Cloudflare accounts. When I created those projects, Cloudflare auto-suffixed them. Bare-name docshub.pages.dev is the site "VIBE HUB // NEO-MINIMAL" (some random other user), and vibe-hub.pages.dev is the "Vibe Hub" site by another account.
The names fv-dochub and fv-vibehub were unclaimed at the time of creation, so we got the bare URLs.
Naming convention (revised from D-063)
| Layer | Value |
|---|---|
| Brand (operator-facing UI text) | fv-dochub / fv-vibehub |
| Cloudflare project name | fv-dochub / fv-vibehub |
| Cloudflare subdomain | fv-dochub.pages.dev / fv-vibehub.pages.dev |
| Repo internal project name | freshvibe-dochub / freshvibe-hub (operator directive 2026-06-23 15:38, temporary) |
| Path inside docHub | /mavis/prompts/ (unchanged) |
| Browser tab title (TBD) | fv-dochub / fv-vibehub |
Now the URL matches the brand and the project name. The repo-internal name remains freshvibe-* per operator's earlier directive (temporary until FVS is stable).
Forward migration plan (when FVS stabilizes)
When the operator migrates to FVS-canonical naming:
- Brand names will unify on whatever FVS picks (likely
doc-huborvibe-hubwithout thefv-prefix) - The Cloudflare project names will be deleted + recreated with the new bare name (only if the new name is unclaimed at that time)
- The repo paths will rename from
freshvibe-dochubto whatever the canonical is - Internal references in decision docs, manifest.json, and the SPA shell will be updated
For now, the brand + URL = fv-*.pages.dev and the repo internal name = freshvibe-* are decoupled. This decoupling is documented and intentional.
Cross-references
mavis/decisions/D-060-dochub-substrate-shape.md— docHub substrate shape (three-flag model)mavis/decisions/D-063-prompt-archive-migration.md— prompt archive migration (uses/mavis/prompts/path)mavis/dangerous/memory-drift.md— lesson on verifying external state (the auto-suffix rule was misremembered; API test corrected it)