v0.3.1 — production validation patches

StudioLayout — site-mode-aware nav (real-test polish)

StudioLayout rendered the same three nav links — Home / Products /
Orders — regardless of site_mode. In showcase mode (no checkout,
no orders) the "Orders" link led to a 404 or a confused empty page.

Fix in packages/bodega/src/components/StudioLayout.tsx: read
BODEGA_SITE_MODE (already set by deploy/SKILL.md Step 5) and
hide "Orders" unless the mode is digital or commerce. Defaults
to showing Orders when the env var is unset, matching pre-mode-aware
behavior so existing 0.2.x deployments don't regress on upgrade.

(Filed as #47 in the validation pass.)

Vercel CLI 52 blob-store subcommand drift (real-test)

hosting/SKILL.md Step 3 documented vercel blob store add bodega-store + vercel blob store connect bodega-store (the CLI
50/51 shape from round 2). On CLI 52 the subcommand surface
re-shifted: store add and store connect no longer exist. The
real shape is vercel blob create-store <name> --access=public --yes,
and there is no separate connect-store subcommand at all — linking
happens during create-store via a "connect to environments?"
prompt that --yes accepts.

Real-test impact: a setup pass got past link and vercel env add,
hit Step 3 with the documented (stale) commands, watched
store add error out, fell into prompt-hang on create-store
without flags, eventually had to wire BLOB_READ_WRITE_TOKEN
manually via vercel env add — which then ran into the
stdin-newline footgun and stored an empty value. Cascading
breakage from one stale subcommand.

Fix in hosting/SKILL.md Step 3:

• Replaced the CLI 50/51 commands with the CLI 52 shape:
  vercel blob create-store bodega-store --access=public --yes.
• Added a 3-row CLI version compatibility table so future drift is
  obvious at a glance.
• Idempotency check via vercel blob list-stores | grep instead of
  re-running create-store (which errors on existing names).
• Documented why each flag is required: --yes is the only way to
  accept the auto-link-to-environments prompt in non-TTY shells (no
  separate connect exists), and --access=public is required
  both by the CLI and by Bodega's SDK code (which writes blobs with
  access: 'public').
• Manual dashboard fallback for the case where CLI somehow can't
  link the store to the project (Storage → bodega-store → Connect
  Project).

Validation findings — round 6

Two real issues surfaced during validation of the round-5 doc fix.

Regression — vercel env pull doesn't decrypt on CLI 52+

The Step 5b "verify-non-empty" check shipped earlier in [Unreleased]
used vercel env pull to fetch .env.production.local and grep for
empty values. This false-positive-fires on Vercel CLI 52+: the pull
writes the file but does not decrypt encrypted/sensitive values
to disk — the values exist only on the runtime. So the verify would
report all secrets as empty even when they were correctly set,
causing the deploy to bail unnecessarily.

Fixes:

• deploy/SKILL.md Step 5b — replaced pull-and-grep with a
  presence-only check via vercel env ls production --json that
  confirms each required env-var name appears in the project (catches
  the never-added case but, by design, can't catch the empty-value
  case — see Step 7.5 for the reliable verify).
• payments/SKILL.md Step 4b — same revert; uses
  vercel env ls production for name-presence only, with explicit
  doc that value-emptiness can't be checked from the CLI on 52+.
• deploy/SKILL.md Step 7.5 (new) — the actual reliable verify is
  a post-deploy smoke test that hits the live /api/bodega/auth/ magic-link endpoint with the in-memory BODEGA_ADMIN_SECRET. The
  HTTP response classifies the failure precisely:
  • 200 → secret + storage both good
  • 401 → BODEGA_ADMIN_SECRET empty/wrong on Vercel (re-add via
    <<< here-string, redeploy)
  • 503 → infrastructure unconfigured (most often
    BLOB_READ_WRITE_TOKEN missing — connect blob store, redeploy)
  • other → check vercel logs <deploy-url>

SDK — opaque 500s when blob storage isn't configured

The admin endpoint (POST /api/bodega/auth/magic-link) was throwing
a generic 500 when BLOB_READ_WRITE_TOKEN was missing — the
underlying blob-storage.ts token() function throws "is not set"
inside createMagicLink(), which Next bubbled up as 500 with no
useful body. Hard for the operator to diagnose.

Fixes (in packages/bodega/src/routes/):

• auth-magic-link.ts — pre-flight check for
  BLOB_READ_WRITE_TOKEN. Missing → 503 with
  { message: "Storage is not configured (BLOB_READ_WRITE_TOKEN missing). Run \vercel blob store connect ` and
  redeploy.", reason: "storage_unconfigured" }. Storage layer errors during createMagicLink()→502with the underlying message +reason: "storage_error"`. Both surfaced by the new
  Step 7.5 smoke test for actionable operator output.
• auth-login.ts — same pre-flight, but on this public endpoint
  the failure is logged server-side (vercel logs) and the response
  stays the constant anti-enumeration message. The operator sees the
  problem in logs without leaking infrastructure state to the
  public.

vercel env add stdin-newline footgun (real-test)

CLI 52+ silently writes empty-string values when stdin closes without
a trailing newline. The printf "%s" "$VALUE" | vercel env add NAME
pattern (no \n) records NAME="" on Vercel and prints "Added"
regardless. All six bodega secrets (BODEGA_SESSION_SECRET,
BODEGA_ADMIN_SECRET, STRIPE_SECRET_KEY, etc.) silently became
empty strings on a real-world setup pass; magic-link login then
401-ed every request because BODEGA_ADMIN_SECRET="" failed the
!expected check in the SDK auth route.

Fixes:

• deploy/SKILL.md Step 5: explicit footgun callout with safe-vs-
  unsafe stdin form table. Bodega scripts already use the safe
  <<< here-string form (which appends \n); the doc now warns
  agents and humans not to "improve" it to printf "%s" /
  echo -n (which both strip the newline).
• deploy/SKILL.md Step 5b (new): pull-and-verify-non-empty
  check after the env-vars block. Pulls .env.production.local,
  greps for empty values among the required secret names, fails
  loud and bails with re-add instructions if any landed empty.
  In-memory only; deletes the file before exit either way.
• payments/SKILL.md Step 4b: same pull-and-verify pattern for
  STRIPE_SECRET_KEY. The previous vercel env ls | grep check
  saw the name but couldn't tell if the value was empty.

The SDK is already defensive — auth-magic-link.ts returns 401 when
BODEGA_ADMIN_SECRET is empty (the existing !expected check
catches it). The bug was always going to be visible at first
magic-link request; the new verify-step catches it three minutes
earlier, before the deploy itself.