test(e2e): functional deploy-failure debug-path live UI spec (the CEO's core ask)#195
Merged
Merged
Conversation
…y withFailedDeploy
The CEO's core ask: CI must FUNCTIONALLY prove the debug path works — "deploy an
app and get its logs; fail a deployment and get its logs/events" — not just that
llms.txt redirects. Adds e2e/live-ui-failure-diag.spec.ts (real backend, minted
cohort, reaped) with three legs:
- Happy deploy → logs (schedule lane): mint pro → create deploy (202) → the
build-logs endpoint authorizes the owner and returns a recognized state
(200 streaming / 409 not_ready-still-building / 404 GC'd, NOT 401/5xx) AND
the LiveBuild SSE panel reaches a rendered stream state in the UI.
- Failed deploy → /events (API, @pr-smoke): mint with_failed_deploy →
GET /api/v1/deployments/:id = status=failed + non-empty error_message;
GET /api/v1/deployments/:id/events = autopsy event with reason (OOMKilled) +
non-empty last_lines + hint; + auth-negative (401) + cross-team (404). This
is the agent auto-debug surface, asserted end to end.
- Failed deploy → UI (FailureAutopsyPanel, @pr-smoke): load
/app/deployments/:id in the browser (minted session) → the panel renders the
reason heading + hint + last_lines (log toggle) against a real backend.
Extends e2e/factory.ts with mintUserWithFailedDeploy() (with_failed_deploy →
failed_deploy_id, api 021bb7e). The two failed-deploy legs are @pr-smoke (fast:
seeded reads + panel render, no real Kaniko build) so the debug surface can't
silently regress on a web PR; the happy real-deploy leg stays on the schedule.
Cohort-tagged + reaped (rule 24); gated on the e2e token (skip-clean).
Verified live against prod api 021bb7e: all 4 legs pass, reap clean
(attempted=8 deleted=5 alreadyGone=3 failed=0, ledger cleared).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
mastermanas805
enabled auto-merge (squash)
June 6, 2026 05:39
size-limit report 📦
|
mastermanas805
added a commit
that referenced
this pull request
Jun 6, 2026
…ty guard (#196) Closes the agent-discoverability half of the failure-diagnosis CI program: an agent that hits a failed deploy must be able to find, from llms.txt alone, that the classified cause is served back over HTTP — and that can't silently regress. - public/llms.txt: synced to content-repo HEAD (PR #27, a10699f) — adds the "Debugging a failed deploy (agent self-recovery)" section + the /docs/troubleshooting-deploys.md reference (the /events autopsy loop: reason + last_lines + hint → fix → redeploy → re-poll). - src/lib/llmsContract.test.ts: new CONTRACT_MARKERS row asserting llms.txt contains BOTH the 'troubleshooting-deploys' reference AND the '/api/v1/deployments/:id/events' debug surface — so a content sync or docs edit that drops the debug path reds CI (verified: removing the events marker fails the test by name). - scripts/fetch-content.mjs: adds the same two markers to the llms.txt requireMarkers lock-step guard — a future upstream sync missing them PRESERVES the committed copy instead of reverting the documentation (rule 22). Pairs with the FUNCTIONAL live proof in e2e/live-ui-failure-diag.spec.ts (#195): discoverable AND demonstrably working. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
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
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.
What
Functionally proves the deploy-failure debug path works end to end against a real backend — the CEO's core ask: "deploy an application and get its logs; fail a deployment and get its logs/events" — not just that llms.txt redirects.
Source:
docs/ci/02-FAILURE-DIAGNOSIS-AND-AUTODEBUG.md§5.4.Three legs, two lanes
e2e/live-ui-failure-diag.spec.ts(real backend, minted cohort, reaped):not_ready-still-building / 404 GC'd — not 401/5xx) AND the LiveBuild SSE panel reaches a rendered stream state in the UI.@pr-smoke: mintwith_failed_deploy→GET /api/v1/deployments/:id=status=failed+ non-emptyerror_message;GET /api/v1/deployments/:id/events= autopsy event withreason(OOMKilled) + non-emptylast_lines+hint; + auth-negative (401) + cross-team (404). This is the agent auto-debug surface, asserted end to end.FailureAutopsyPanel) —@pr-smoke: load/app/deployments/:idin the browser (minted session) → the panel renders the reason heading + hint + last_lines (log toggle) against a real backend.Extends
e2e/factory.tswithmintUserWithFailedDeploy()(with_failed_deploy→failed_deploy_id, api021bb7e).Why
@pr-smokeon two legsThe two failed-deploy legs are fast (seeded reads + panel render, no real Kaniko build), so they run on every web PR (
e2e-pr-smoke.yml --grep @pr-smoke) — the debug surface can't silently regress. The heavier real-deploy happy leg stays on the 30-min schedule.Verification (live, not asserted)
Ran against real prod (api
021bb7e) with the e2e mint token — all 4 legs PASS, reap clean (no leak, rule 24):npm run gategreen (tsc + build + prerender + 1129 vitest).Note (honest finding, not a bug)
A just-202'd deploy's
GET /deploy/:id/logslegitimately returns409 not_ready(noprovider_iduntil the build pod exists —deploy.go:1571). The happy-leg assertion accepts that honest state (200/409/404) and only fails on 401/5xx.🤖 Generated with Claude Code