fix(public): enforce trust/support JSON-LD on the live site and deploy bundle - #83
fix(public): enforce trust/support JSON-LD on the live site and deploy bundle#83nish3451 wants to merge 9 commits into
Conversation
…y bundle
The Grok review finding ("six trust/support pages carry no JSON-LD while
the other six do") describes the live tinystudio.in, which has served the
2026-06-20 bundle (07acd07) since June 20. The repo fix itself is already
merged on main (PR #26 adds JSON-LD to every public page; the structured
data test asserts all 12 pages), but the release lane's detectors only
proved JSON-LD on /contact/, so the finding could recur silently.
Close the detector blind spots so the acceptance is enforced end-to-end
once the release lane publishes:
- scripts/check-public-live-deploy.mjs: new section E asserts every one
of the 12 public paths returns 200 and carries exactly one
application/ld+json block, mirroring the repo-side invariant from PR #26
(currently fails live: 8 pages on the stale bundle have zero JSON-LD).
- scripts/prepare-public-deploy-bundle.mjs: NEUTRAL_PROOFS now asserts
JSON-LD survival for every remaining public page, so the filtered
deploy bundle fails closed if any page loses its structured data
(test-public-deploy-bundle.mjs: 62 -> 72 checks).
verify: npm test (all green); node scripts/test-public-deploy-bundle.mjs
(72 checks, 0 failures); node scripts/check-public-live-deploy.mjs now
reports the 8 live pages missing JSON-LD, proving the detector catches
the original finding; git diff --check
|
Warning Review limit reached
Next review available in: 39 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: Free Run ID: 📒 Files selected for processing (2)
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 |
![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.
![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: 786e965085
ℹ️ 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".
| { | ||
| label: "support page JSON-LD (07acd07 baseline)", | ||
| file: "support/index.html", | ||
| test: (html) => html.includes("application/ld+json"), |
There was a problem hiding this comment.
When a page loses its JSON-LD <script> but retains the text application/ld+json elsewhere—for example, in an HTML comment—this proof still passes, so preparePublicDeployBundle() can produce a publishable bundle without structured data despite the stated fail-closed invariant. This affects every newly added proof because they all use the same substring check; count complete JSON-LD script blocks (and require exactly one) instead.
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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1fa65cb54f
ℹ️ 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".
| for (const path of PUBLIC_PATHS) { | ||
| const { status, body } = await get(path) | ||
| ok(status === 200, `${path} returns 200 (got ${status})`) | ||
| const blocks = (body.match(/<script\s+type="application\/ld\+json"[^>]*>/gi) || []).length |
There was a problem hiding this comment.
When a live response contains this opening-tag text inside an HTML comment, or contains one unterminated or syntactically invalid JSON-LD script, blocks is still 1, so section E reports success even though consumers have no usable structured data. This live acceptance check should extract complete opening/closing script blocks and parse their contents as JSON before counting them as valid.
Useful? React with 👍 / 👎.
| ] | ||
|
|
||
| // Every public page on the live site must carry structured data (PR #26). | ||
| const PUBLIC_PATHS = [ |
There was a problem hiding this comment.
When a new public/**/index.html page is added, the bundle copies and publishes it but this manually maintained array does not automatically include it, so the claimed site-wide live invariant silently stops at the original 12 routes. This is especially problematic for detecting another stale deployment: the new route can be absent or lack JSON-LD while post-deploy verification succeeds. Derive this inventory from the deploy bundle or another canonical route manifest, or add a synchronization check against the public pages.
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.
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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aaaa24ca84
ℹ️ 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 blocks = (body.match(/<script\s+type="application\/ld\+json"[^>]*>/gi) || []).length | ||
| ok(blocks === 1, `${path} carries exactly one application/ld+json block (got ${blocks})`) |
There was a problem hiding this comment.
When a listed route is misconfigured to return another page with status 200—for example, /drishti/privacy/ serving the homepage—this check passes because the homepage also contains exactly one JSON-LD opening tag. The unknown-URL test does not detect a rewrite or duplicated artifact affecting only a known route, so the release lane can approve a deployment where the requested page and its route-specific structured data are absent; compare the response canonical or parsed JSON-LD URL with path before accepting it.
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.
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.
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.
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.
1 participant
The item
[unreviewed-by-grok] Six trust/support pages carry no JSON-LD structured data while the other six public pages do
Root cause
The finding describes the live site (tinystudio.in), which has served the stale 2026-06-20 bundle (
07acd07) since June 20. Live JSON-LD coverage today: only/,/support/,/promptly/,/drishti/(4 of 12 pages);/contact/,/privacy/,/privacy-choices/,/terms/,/promptly/support/,/promptly/privacy/,/drishti/support/,/drishti/privacy/carry zero JSON-LD.The repo fix is already merged on main: PR #26 added JSON-LD to every public page and
test-public-structured-data.mjsasserts all 12 pages (127 checks, 0 failures). The release lane (#81) exists to publish main, but fail-closes without a Cloudflare Pages API token (one-time provisioning documented inpublish-public-site.mjs).What this PR closes: the detector blind spots
The instance was fixed in #26, but the release lane only proved JSON-LD on
/contact/- the exact finding could recur silently. This PR makes the acceptance enforced end-to-end:scripts/check-public-live-deploy.mjs- new section E asserts every one of the 12 public paths returns 200 and carries exactly oneapplication/ld+jsonblock (mirrors the PR fix(public): add JSON-LD structured data to trust and support pages #26 repo-side invariant). Run against the live site today it fails on exactly the pages the Grok review flagged.scripts/prepare-public-deploy-bundle.mjs-NEUTRAL_PROOFSnow asserts JSON-LD survival for every remaining public page, so the filtered deploy bundle fails closed before publish if any page loses its structured data (test-public-deploy-bundle.mjs: 62 -> 72 checks).Verification
npm test- all green (structured-data 127 checks, deploy-bundle 72 checks, 0 failures)node scripts/check-public-live-deploy.mjs- now reports the 8 live pages missing JSON-LD (detector catches the original finding; passes only after the release lane publishes main)git diff --checkcleanNote
The actual publish to production remains blocked on the documented one-time provisioning of a Cloudflare Pages-scoped token (
gh secret set CLOUDFLARE_API_TOKEN,CLOUDFLARE_ACCOUNT_ID=f670a698e17bf160c8e4679823e68916) - no repo secret or local wrangler auth exists.