fix(public): restore the Promptly support heading hierarchy in production (fresh live guard, supersedes stale PR #77) - #128
Conversation
…-heading finding (fresh, superseding stale PR #77) The 2026-08-08 scout item named /promptly/support/: the source outline was repaired by PR #20 (H1 -> H2 cards) and origin/main carries the fixed markup, but production still serves the June-20 bundle - the deployed page jumps H1 -> H3 (verified live 2026-08-12) and the deployed stylesheet keeps the old .info-card h3-only rule, so the finding stays open against tinystudio.in. The closed live-delivery item's guard (PR #77, fix/lane1-promptly-support- heading-hierarchy-live-guard) was never merged: it conflicts with current main and its script asserted npm test/ci wiring that its own header forbids. This lands the guard fresh from origin/main following the fleet's settled convention (standalone, out of the blocking chain, in the nightly net - matching PR #118 for the other two repaired pages): - scripts/test-public-heading-hierarchy.mjs now asserts public/promptly/support/index.html (68 checks, 0 failures; the scout's own page was previously unasserted in source) - scripts/test-public-live-promptly-support-heading.mjs (new): re-asserts the repaired outline + card-heading CSS rule against the live site; network-tolerant skip, fails loudly while the stale bundle is served (verified: 14 checks, 8 failures against the current deployment) - npm run site:check-live-promptly-support-heading on-demand entry point - .github/workflows/live-site-check.yml: nightly job alongside soft-404 The deploy acceptance (scripts/check-public-live-deploy.mjs, already on main) verifies H2-after-H1 on /promptly/support/ the moment the release lane publishes; the lane stays dormant until the Pages-scoped CLOUDFLARE_API_TOKEN secret is provisioned (documented NEEDS-NISH step).
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
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: 34 minutes Limit details: You’ve used the included review currently available. 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 within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (4)
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 14c397d6a0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (!res.ok) { | ||
| console.log(` ok skipped: ${url} answered ${res.status}, deployment not reachable - no assertions run for it`) | ||
| return null |
There was a problem hiding this comment.
When /promptly/support/ or /styles.css responds with a 404 or 5xx, fetch succeeds but this branch returns null, so all assertions for that resource are skipped and the nightly job can exit successfully. In particular, the companion live-soft-404 job checks /promptly/ rather than /promptly/support/, so a missing support route can leave the entire workflow green; reserve the network-tolerant skip for actual connection failures and count non-2xx HTTP responses as failures.
Useful? React with 👍 / 👎.
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.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e862943b6b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| const fetchLive = async (url) => { | ||
| try { | ||
| const res = await fetch(url, { signal: AbortSignal.timeout(FETCH_TIMEOUT_MS) }) |
There was a problem hiding this comment.
When /promptly/support/ is redirected to /promptly/, fetch follows the redirect by default and this guard still passes: the Promptly landing page also has exactly one H1, three .info-card H2 headings, at least four H2s, no heading-level jumps, and uses the same stylesheet. Consequently, a missing support destination can leave the nightly job green; fetch with redirect: "manual" or verify that the final response URL still identifies /promptly/support/ before asserting its body.
Useful? React with 👍 / 👎.
…812 (resolve #128) # Conflicts: # .github/workflows/live-site-check.yml # package.json
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
1 participant
Why
The 2026-08-08 scout item "Restore the Promptly support heading hierarchy in production" stays open: the source outline on
/promptly/support/was repaired by PR #20 (H1 -> H2 cards), but production still serves the June-20 bundle — the deployed page jumps H1 -> H3 (verified live 2026-08-12: outline [1,3,3,3,2,3,3,3]) and the deployed stylesheet keeps the old.info-card h3-only rule, so the finding silently stays open against tinystudio.in.The closed live-delivery item's guard (PR #77,
fix/lane1-promptly-support-heading-hierarchy-live-guard) was never merged: it conflicts with current main, and its script asserted npm test/ci wiring that its own header forbids. This PR lands the guard fresh from origin/main following the fleet's settled convention (standalone, out of the blocking chain, in the nightly net — matching PR #118 for the other two repaired pages).What
scripts/test-public-heading-hierarchy.mjs: now assertspublic/promptly/support/index.html(68 checks, 0 failures; the scout's own page was previously unasserted in source).scripts/test-public-live-promptly-support-heading.mjs(new): re-asserts the repaired outline (exactly one H1 first, three H2 card titles inside.info-card, flat H2 band before footer H3s, no heading-level jump greater than one) and the shared.info-card :is(h2, h3)rule at the former card scale against the live site. Network-tolerant (skips when unreachable); fails loudly while the stale bundle is served.npm run site:check-live-promptly-support-headingand into the nightlylive-site-check.ymlstaleness net (alongside the soft-404 check). Deliberately NOT part ofnpm run test/npm run ci— blocking chains stay green on repo state alone, same convention as PR fix(public): guard the live site against skipped heading levels on Drishti support and Privacy Choices pages #118.scripts/check-public-live-deploy.mjs, already on main) verifies H2-after-H1 on/promptly/support/the moment the release lane publishes.Current status
The live guard intentionally fails against the live site right now (14 checks, 8 failures — all stale-deployment detections), keeping this item visibly open until production is refreshed. The release lane (
deploy-public-site.yml) stays dormant while the Pages-scopedCLOUDFLARE_API_TOKENsecret is absent from repo secrets (documented NEEDS-NISH provisioning step, PR #111); the moment both secrets exist, every main merge publishes the fixed bundle and the deploy acceptance + this guard go green.Verify
node scripts/test-public-heading-hierarchy.mjs→ 68 checks, 0 failuresnode scripts/test-public-live-promptly-support-heading.mjs→ 14 checks, 8 failures (stale-live detection, expected until redeploy)node --check scripts/test-public-live-promptly-support-heading.mjs→ cleangit diff --check→ cleannpm test→ matches clean main (only pre-existing retention-automation exit-1, reproduced on a clean origin/main worktree)