test: diagnose stale-deploy SPA fallback in live promise spot-check - #67
Conversation
The lane-2 promise audit found the live /check page fails the spot-check, but the failure was misdiagnosed as copy drift. The deployed Worker predates the /check route (commit 4bd9868, #66): /check is served by the static-asset SPA fallback (id="root" shell) instead of the Worker route, and POST /api/public-check returns 405. The spot-check now detects the SPA fallback and reports it as a stale deployment (deploy main, then rerun) instead of pointing at the copy or the claim. Adds a test that worker-rendered pages are never flagged.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reached
Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Comment |
What this is
Lane-2 promise audit: verify every claim in README "What is live in this
repo" and spot-check the live /demo, /methodology, /packages pages.
Audit result
Offline half — green. All 56 pins in
shared/promise-audit.test.mjslock every "What is live in this repo" bullet to code, and they pass
(
npm run checkexit 0, 300 tests, 0 failures). Every README claim isbacked by code.
Live half — one real gap found.
npm run audit:live-promiseagainsthttps://seofixkit.com:
/demo— ok (proof loop before payment)/methodology— ok (limits up front)/packages— ok (package ladder before payment)/check— FAIL: the deployed site does not serve the anonymous one-pagecheck the README promises (bullet 44 and the Check section).
Root cause: stale deployment, not copy drift
The deployed Worker predates commit
4bd9868(#66, merged 2026-08-09):GET /checkreturns the static-asset SPA homepage (title "SEO Fix Kit -Proof-Backed SEO Repair Beta",
<div id="root">,content-type: text/htmlwithout charset) instead of the check page — the Worker route is absent.
POST /api/public-checkreturns 405 (the assets fallback), not the JSONvalidation/rate-limit responses the route would produce.
/sitemap.xmllacks/check(main'srootSitemapincludes it)./demoand/packagespages predate feat: add public anonymous one-page check as the proof-to-repair entry path #66's "Check one pagenow" CTA copy.
The code on main is correct and the offline pins pass; production simply has
not been redeployed since #66 merged. Deploy requires Cloudflare credentials
(expired wrangler OAuth token, no CI deploy workflow — the repo deliberately
has none), so this PR cannot deploy; the operational fix is
npx wrangler deployfrom main, then rerunnpm run audit:live-promise.What this PR changes
The spot-check previously told the operator to "fix the deployed copy or the
claim in the spot-check" for any failure. For the /check failure mode the
copy and the claim are both correct — the deployed Worker is simply stale.
The script now detects the SPA static-asset fallback (
id="root"shell +text/htmlwithout charset, which worker-rendered promise pages neverproduce) and reports:
and the summary tells the operator to deploy the current Worker. Added a
test proving worker-rendered pages are never flagged.
Validation
npm run test:live-promise-spot-check— 5/5 pass (new stale-deploy test included)npm run check— exit 0, 300 tests, 0 failures, build oknpm run audit:live-promiseagainst https://seofixkit.com — reports thestale-deploy diagnosis for /check; /demo, /methodology, /packages pass