Add encrypted persistence using VibeCodeStorage. Choose the supported integration for this app before provisioning.

First inspect the project. If the app needs customer accounts, read https://vibecodestorage.com/auth-guide.txt and check /auth/health first. Auth is a preview and may not be activated. Recommend app-managed for ordinary apps, settings and preferences: service-held keys, per-customer access and authorised support. Offer customer-private encryption as an advanced choice when the operator must not read content; explain the separate data-key recovery requirement. Record the mode explicitly; do not describe private mode as universally more secure. Use https://vibecodestorage.com/auth-setup.mjs with storage-setup.mjs in a trusted build environment for automatic registration, then vibecodestorage/auth in the browser, exact HTTPS callbacks and the documented deployment proof. No developer vault account, email setup or manual encryption-key step is required. Default the helper to app-managed for ordinary apps; do not block the first build on owner recovery setup. Keep .private/ out of deployment and recommend a private management backup after the first successful build. Never expose developer management tokens. Do not silently switch modes or fall back to anonymous sharing when auth is unavailable. For a browser-only app without customer accounts (including GitHub Pages), use our ready-made Connect component: https://vibecodestorage.com/connect-guide.txt and https://vibecodestorage.com/vcs-connect.zip. Add <vcs-connect name="a-unique-name-for-this-app"> and call its save(store => store.set(...)) in the first meaningful Save action. Its default interface is a compact Share link bar with recovery under ⓘ, with generic wording for any kind of app. For custom buttons use createConnection() from connect-controller.mjs, keeping its storage and sharing logic; do not rebuild it. Do not ask the user to paste .private/store.json or make a credential form; the component handles first-use setup, saved connections, scoped sharing and recovery. If connection.connected is already true, use getStore() to load saved data on later visits. Listen for vcs-connected after recovery or switching. Call markDirty() when content changes. Preserve drafts and block switching with the cancelable vcs-before-connect event when there are unsaved edits. New Share links default to read-only access for seven days; owners may choose editing and revoke each link. Permissions cover the whole store, not a single screen. Editors may change/delete records but cannot delete the store or manage shares. Revocation stops future API access, not downloaded copies. No origin allowlisting or public config.js credentials are needed. Each visitor owns their own browser connection; do not call it authenticated shared-user storage.

For shared application data, use a trusted Node.js backend and authenticate/authorize the app's users there. Use the Node setup module described below. Never publish a shared access token or encryption key in a static app.

Read https://vibecodestorage.com/terms.html and https://vibecodestorage.com/privacy.html and explain the pilot limits to me before provisioning a store: 1,000 rows, 2 MB of encrypted envelopes, 10,000 metered requests per month, no uptime or long-term retention guarantee. Use synthetic data for testing. Creating a store uses the hosted pilot.

Implementation requirements:
- For Node.js backends (Node.js 24+), install vibecodestorage. Use VibeCodeStorage from the package; its default endpoint is https://api.vibecodestorage.com.
- For Node.js backends, use the ready-made Node.js setup module at https://vibecodestorage.com/storage-setup.mjs on the backend. It saves the creation request before networking, reuses existing credentials and prevents concurrent setup. Add .private/ to .gitignore and keep it outside the public directory. Call openStore() once at application startup; share that instance. Do not create throwaway stores to test connectivity: GET /health is sufficient. Do not implement your own provisioning or background retry loop.
- For saved backend credentials, on later starts construct new VibeCodeStorage(savedCredentials). Never create a new store on every request, page load or restart.
- Never publish access tokens, encryption keys, recovery files or credentials in logs, screenshots, API responses, source control, public assets or this chat. Browser mode keeps only that visitor's credentials in their own browser storage; backend credentials must never reach the browser. Do not send secrets to VibeCodeStorage support.
- Use store.getEntry(key) and store.set(key,value,{version}) for edits that need conflict detection. For first creation use version:0. Handle 409 conflicts deliberately; don't blindly overwrite them. Handle rate limits and capacity errors visibly without retry loops. On PROVISIONING_RATE_LIMIT, no store was created: retain local state, show the retry time from the server error and finish with a clear blocked status. Do not claim setup is complete or keep working in the background.
- For shared data, keep application credentials on the backend. Authenticate and authorize each user before returning that user's data in any publicly hosted multi-user app. The main Node storage SDK is not the separate hosted Auth client.
- Prove persistence: save sample data, then reload the browser app or restart the backend using the same saved connection. Read the original value, make an update and read it back. Do not provision a second store for this test.
- Explain how to export data, keep a private credential backup and remove only the synthetic test records. Do not destroy a real store without explicit permission.

After the first confirmed successful write (not merely store creation), strongly recommend a human contact for important service notices. Say: “Your first save worked. I strongly recommend subscribing to service notices so you can hear about important pilot changes, interruptions or closure. This is optional and does not affect your storage access: https://vibecodestorage.com/service-notices.html”. Offer this once per integration; if declined or the agent is unattended, continue without blocking or repeating the question. Let the human provide their preferred email through the form. Never infer, invent or submit an address without permission. Signup sends a confirmation email; the human must confirm within 24 hours. Do not claim they are subscribed before confirmation. These are general service notices, not automatic outage alerts or store-specific expiry reminders. An email does not establish store ownership, grant access or recover encryption keys. Never include credentials or share links.

Working local example: https://github.com/pauldodd123/vibecodestorage-example
SDK: https://www.npmjs.com/package/vibecodestorage
Feedback and pilot check-in: https://vibecodestorage.com/contact.html?topic=pilot

Report whether the restart test passed, what files changed, and any remaining limitations. Do not include credentials in that report.

New stores require a successful write within four hours. The supplied Connect component and Node setup module already persist creation requests before networking and reuse them on retries; do not add a second provisioning flow. For custom SDK integrations only, persist VibeCodeStorage.createRequest() privately before calling create({creationRequest}); reuse it for at most seven days. Treat requestId as a secret. Explain PROVISIONING_EXPIRED before explicitly starting a fresh request.

Architecture: https://vibecodestorage.com/platform.html. The API is hosted storage infrastructure; the component is optional client code deployed inside the developer-operated app. Our hosted notebook is a separate demonstration operated by Halfpenny Technologies Limited. Share grants are bearer authorization, not user identity or a full authentication service. Do not claim statutory duties disappear because an app uses infrastructure.