Enable sync only for vibe-viewer context + simplify ClerkTokenStrategy

[jchris]

Summary

• Modified useFireproof to conditionally enable sync only when vibeMetadata exists
• This ensures only instance-specific databases (running in vibe-viewer) get synced
• Simplified ClerkTokenStrategy to pass tokens through without decoding/parsing claims
• Upgraded @adviser/cement to 0.5.2 to match Fireproof dependencies
• Updated tests to mock VibeContext for proper sync testing

Changes

1. Conditional Sync Based on Vibe Context - Sync is now only enabled when vibeMetadata (titleId + installId) exists, which happens in the vibe-viewer route
2. Simplified Token Strategy - ClerkTokenStrategy now just returns tokens without decoding claims
3. Dependency Upgrade - @adviser/cement upgraded from 0.4.66 to 0.5.2
4. Test Updates - Added mocks for Clerk auth and VibeContext

Test Results

All 748 tests passing ✅

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for fireproof-ai-builder canceled.

Name	Link
🔨 Latest commit	db45ee9
🔍 Latest deploy log	https://app.netlify.com/projects/fireproof-ai-builder/deploys/69302e6620925900080948e4

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[charliecreates]

The main functional issue is that toCloud accepts a tokenStrategy but never forwards it to originalToCloud, so ClerkTokenStrategy is not actually used for sync auth. There are also architectural concerns: useFireproof now hard-depends on Clerk at runtime and has removed prior user-controlled sync toggling, which may be an intentional but breaking behavior change. Token fetching in ClerkTokenStrategy lacks any caching, which could introduce unnecessary load on Clerk. Tests correctly mock new dependencies but may benefit from a small abstraction to make sync gating via VibeContext more explicit and reusable.

Additional notes (6)

• Readability | use-vibes/base/clerk-token-strategy.ts:22-29
  The ClerkTokenStrategy methods stop and open are currently empty no-ops. While that may be correct for Clerk, the lack of any logging or comments about potential future behavior makes it easy for someone to miss these hooks if additional lifecycle work becomes necessary (e.g., revoking listeners, reacting to device changes).

Given this is a strategy used in a sync pipeline, it would be safer either to document that no lifecycle management is required or to add minimal logging to aid in debugging.

• Maintainability | use-vibes/base/index.ts:72-80
toCloud now accepts a tokenStrategy in its options, but the implementation unconditionally forwards only the original opts spread plus hard-coded URIs and urls. If the caller passes opts.tokenStrategy, it is never forwarded to originalToCloud, so the ClerkTokenStrategy is effectively ignored.

This is a logical bug: useFireproof computes tokenStrategy and passes it into toCloud({ tokenStrategy: tokenStrategy as TokenStrategie }), but the strategy is dropped here, meaning the intended Clerk-based auth for sync is not actually wired up. This contradicts the PR summary that ClerkTokenStrategy is integrated as the sync auth mechanism.

• Maintainability | use-vibes/base/index.ts:109-109
useFireproof now unconditionally calls useAuth() from @clerk/clerk-react, and @clerk/clerk-react is only declared as a peer dependency. This means any consumer of @vibes.diy/use-vibes-base that doesn’t have Clerk set up (e.g., internal tools, tests, or different auth providers) will hit a runtime error when this hook is used, even if they never intend to sync.

This is a coupling concern: a base hook that’s meant to be generally reusable in the use-vibes ecosystem now hard-depends on Clerk at runtime rather than making auth pluggable. A failure to provide a Clerk provider will likely throw during render, which is brittle for non-viewer contexts the PR aims to treat differently. It also makes it harder to swap auth providers in the future.

• Performance | use-vibes/base/index.ts:128-133
getToken is captured in a useMemo dependency array, but depending on Clerk's implementation this function reference may be unstable (e.g., recreated on each render). That would cause ClerkTokenStrategy to be re-instantiated frequently, which may defeat the purpose of memoization and could lead to subtle behavior differences if the strategy is expected to be long-lived.

If useAuth().getToken is stable per Clerk's docs, this is fine; if not, you risk unnecessary churn in the token strategy construction on every render.

Given the current code, the useMemo adds complexity with limited benefit unless you can rely on getToken stability.

• Maintainability | use-vibes/tests/useFireproof.bodyClass.test.tsx:28-28
  The change in sync gating—from wasSyncEnabled + localStorage to vibeMetadata presence—means that tests or code paths that previously exercised sync in non-vibe-viewer contexts will now always see syncEnabled === false unless useVibeContext returns metadata. The test fixes this by mocking useVibeContext, but there’s still an implicit coupling here: any future tests around sync must remember to mock the context, or they’ll silently see sync as disabled.

To make tests more robust and less dependent on implicit knowledge of context gating, it may be worth centralizing a small helper or factory for test setups that require sync, or at least documenting in the test suite that useVibeContext must be mocked when testing sync-related behavior.

• Maintainability | use-vibes/tests/useFireproof.bodyClass.test.tsx:28-36
  The test now mocks useVibeContext by intercepting @vibes.diy/use-vibes-base, which is also the module under test. This pattern works but tightly couples the test to the package's barrel exports and may be fragile if you refactor entry points or split the context into a separate file.

If VibeContext is defined in a dedicated module (e.g., ./contexts/VibeContext), it would be more robust to mock that module directly rather than the entire base package.

Summary of changes

Summary of Changes

• Upgraded @adviser/cement to ^0.5.2 and aligned use-fireproof lockfile entry with that version.
• Added @clerk/clerk-react as a peer and dev dependency for the use-vibes/base package.
• Introduced a new ClerkTokenStrategy class implementing Fireproof's TokenStrategie interface, delegating token acquisition to a provided getToken function and passing tokens through without decoding claims.
• Updated the toCloud helper to accept an optional tokenStrategy and wired useFireproof to:
  • Use Clerk's useAuth().getToken via ClerkTokenStrategy.
  • Enable sync only when vibeMetadata exists and pass the tokenStrategy into toCloud.
  • Treat sync as enabled based solely on Fireproof attach state, removing localStorage-based sync toggling and stub enableSync/disableSync callbacks.
• Adjusted tests to mock @clerk/clerk-react and VibeContext so sync can be exercised in tests that depend on body class behavior.

[charliecreates]

The new @clerk/clerk-react peer dependency is versioned as >=5.0.0, while the devDependency is pinned with ^5.57.0. This is a fairly wide range for consumers, and if Clerk introduces breaking changes in a later 5.x patch/minor that affect useAuth().getToken, consumers could see runtime issues that won't be caught by your dev setup.

Given you directly depend on useAuth behavior, a tighter peer range (or at least documenting tested versions) would help avoid subtle integration bugs in downstream apps.

Suggestion

Consider narrowing the peer dependency range to the versions you actively test against, for example:

"peerDependencies": {
  "@clerk/clerk-react": "^5.57.0",
  "react": ">=19.1.0"
},
"devDependencies": {
  "@clerk/clerk-react": "^5.57.0",
  // ...
}

Alternatively, document in the README which Clerk major/minor you validate, and adjust the semver range accordingly. Reply with "@CharlieHelps yes please" if you'd like a commit updating the peer range and adding a brief note to your package docs/changelog.

[github-actions]

🎉 Hosting Preview Deployment

Preview URL: https://pr-716-vibes-hosting-v2.jchris.workers.dev
Worker: pr-716-vibes-hosting-v2
Commit: ce54f53

Test the preview:

1. Visit the preview URL above
2. Test hosting functionality (KV assets, queue operations)
3. Verify API integrations work correctly
4. Check domain routing is disabled (workers.dev only)

---

_{This preview will be automatically updated on each push to this PR}

[jchris]

Import Resolution Fixed ✅

This PR now correctly handles the use-fireproof → use-vibes import transformation across all loading scenarios:

What Was Fixed

1. Added importmap to use-vibes-base package.json - Tells esm.sh to resolve use-fireproof to the correct version (0.24.1-dev-memo) when bundling the package

2. Updated vibe-viewer transform - The transformImportsDev function now transforms use-fireproof imports to use-vibes before executing vibe code

3. Added browser-side importmap redirects - Redirects any remaining use-fireproof@0.24.0 requests to the dev-memo version

How It Works

When a vibe is loaded in the viewer at /vibe/:titleId/:installId:

1. Vibe code is fetched from https://{titleId}.vibesdiy.app/App.jsx
2. transformImportsDev transforms import { useFireproof } from "use-fireproof" → "use-vibes"
3. Browser loads use-vibes@0.18.12-dev from esm.sh
4. The package's importmap ensures any transitive use-fireproof imports resolve correctly
5. useFireproof hook detects it's in a vibe-viewer context (has vibeMetadata + getToken)
6. Sync is automatically enabled and logged to console

Console Output

You'll now see logs like:

[useFireproof] 🎉 First call to useFireproof hook
[useFireproof] RENDER 0.1234567
[useFireproof] getToken changed? true
[useFireproof] vibeMetadata changed? true
[useFireproof] augmentedDbName: vf-memo-vault-london-discovery-6406-42388213
[useFireproof] Got fpResult, attach state: attaching

Sync is now automatically enabled for all vibes! 🎉

[jchris]

I think the remaining issue might be on the fireproof side with dashboard env handling

[jchris]

maybe this is all we need