docs(agents): three deploy gaps observed during M10/M11 ramp#16
Closed
ByteStreams-AI wants to merge 1 commit intomainfrom
Closed
docs(agents): three deploy gaps observed during M10/M11 ramp#16ByteStreams-AI wants to merge 1 commit intomainfrom
ByteStreams-AI wants to merge 1 commit intomainfrom
Conversation
… ramp
Three CLI-vs-CI deployment behaviors silently break production. All
three observed in a single afternoon while bringing M10's Knowledge
Base into cloud (May 4, 2026):
5a. `db push` not part of deploy.yml — M10's migration 0012 didn't
land in cloud after PR #14 merged. Discovered when
knowledge_reindex returned 500 (OpenAI embed succeeded; the
knowledge_replace_chunks RPC didn't exist). Already documented;
keeping the entry intact.
5b. `supabase functions deploy <name>` defaults to verify_jwt=true.
CI passes --no-verify-jwt; local CLI does not. Re-deploying any
Vapi-reachable function from a local shell with default flags
breaks Vapi (no apikey or Authorization header on
assistant-request POST → Kong rejects). Discovered when an
OpenAI key rotation re-deploy broke vapi_call_start.
5c. `pnpm deploy:admin` (and `:kitchen`) silently fall back to
Vite dev defaults when VITE_SUPABASE_URL / VITE_SUPABASE_ANON_KEY
aren't in the shell. Build succeeds, deploy succeeds, the
bundle points at http://127.0.0.1:54321 → unreachable from real
browsers. Discovered after deploying admin from a shell that
didn't have the cloud env vars exported.
The CI workflow is the only deploy path that's correct today —
operators running pnpm deploy:* / supabase CLI commands against
cloud need to remember to set the right flags + env vars every
time. M12/M13 should fix this with either:
- A `migrate.yml` workflow gated on a label or workflow_dispatch
confirmation flag (don't auto-push migrations on every commit;
destructive migrations need a human gate)
- A `pnpm cloud:deploy` wrapper that fails loudly when required env
vars are missing, OR remove `pnpm deploy:*` entirely and force
operators through CI
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| **5c. `pnpm deploy:admin` (and `:kitchen`) silently fall back to Vite dev defaults when `VITE_SUPABASE_URL` and `VITE_SUPABASE_ANON_KEY` aren't in the shell.** Vite embeds those values into the browser bundle at build time. CI injects them from GitHub Actions secrets pointing at cloud; a local `pnpm deploy:admin` without them produces a bundle pointing at `http://127.0.0.1:54321` (Vite dev fallback). The build succeeds, deploy succeeds, the deployed app is unreachable from real browsers. **Today's manual fix:** prepend the cloud env vars when running locally: | ||
|
|
||
| ```bash | ||
| VITE_SUPABASE_URL=https://klzznfagrtormretqsgb.supabase.co \ |
Contributor
There was a problem hiding this comment.
The actual Supabase project URL https://klzznfagrtormretqsgb.supabase.co is embedded in the docs while the anon key is wisely left as '<cloud anon key>'. Although VITE_SUPABASE_URL ends up in the browser bundle and is not a secret, using a concrete value here while sibling fields use placeholders is inconsistent and means any future project ref rotation requires a docs update. Consider replacing with https://<project-ref>.supabase.co to match the placeholder style used for the key.
Suggested change
| VITE_SUPABASE_URL=https://klzznfagrtormretqsgb.supabase.co \ | |
| VITE_SUPABASE_URL=https://<project-ref>.supabase.co \ |
This was referenced May 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes the loop on the operational incident from this afternoon: bringing M10's Knowledge Base online in cloud surfaced three distinct CLI-vs-CI deployment behaviors that silently break production. Each one has a one-line manual workaround today; M12/M13 should consolidate the fix.
Expands AGENTS.md "Open follow-up #5" from a single bullet (just the
db pushgap) to a structured entry covering all three:db pushnot in deploy workflow → M10's migration 0012 never landed in cloud after PR PR - M10 — Knowledge Base (RAG) #14 mergedsupabase functions deploy <name>defaults toverify_jwt=true→ broke Vapi after the OpenAI-key-rotation re-deploypnpm deploy:adminfalls back to Vite dev defaults whenVITE_SUPABASE_URL/VITE_SUPABASE_ANON_KEYaren't exported → bundle pointed athttp://127.0.0.1:54321, unreachable from real browsersEach entry lists the symptom, root cause, and today's manual fix.
Why this matters now
M11's E2E testing (the next milestone) will hit this surface repeatedly — every test session needs cloud functions / migrations / app builds to stay in sync. The CI workflow is the only path that's correct today, but it's only triggered automatically on merge. Manual deploys from a maintainer's shell are the most likely operational pattern during M11 voice-testing rehearsals, and each pattern has a foot-gun.
Recommended fixes (M12 or M13)
A single workflow refactor addresses all three:
migrate.ymlworkflow, gated on amigrate-on-mergePR label or aworkflow_dispatchwithconfirm_migrations: yes. Don't auto-push migrations on every commit — destructive migrations need a human gate.pnpm cloud:deploywrapper that fails loudly when required env vars / flags are missing, or removepnpm deploy:*from the package scripts entirely and force operators through CI.Test plan
🤖 Generated with Claude Code
Greptile Summary
Pure documentation update expanding "Open follow-up #5" in
AGENTS.mdinto three structured sub-entries (5a: missingdb pushin CI, 5b: missing--no-verify-jwton manual deploys, 5c: Vite env-var fallback to localhost). Each entry accurately describes a real production foot-gun observed during M10/M11 ramp-up, includes a manual workaround, and defers the proper fix to M12/M13. No code changes.Confidence Score: 4/5
Safe to merge — docs only, no code changes, two minor P2 style nits.
All findings are P2 style issues (stale section header date, inconsistent placeholder vs. real URL). No logic or security concerns in a pure documentation PR.
AGENTS.md — minor date and placeholder inconsistencies noted above.
Important Files Changed
Comments Outside Diff (1)
AGENTS.md, line 116 (link)The section heading reads
## Open follow-ups (May 3, 2026)but item 5 explicitly documents events from May 4, 2026 and is the most recent entry. Readers scanning the header for "last updated" context will get a date that's one day off.Reviews (1): Last reviewed commit: "docs(agents): expand follow-up #5 with t..." | Re-trigger Greptile