fix(public): verify the shared footer copy in the live deploy acceptance - #97
Conversation
PR #35 replaced the launch-prep footer line ('gives each product a clean public foundation before launch') with visitor-facing copy on all twelve shared-footer pages, but the deploy-path acceptance (check-public-live-deploy.mjs) never verified the footer copy - so a stale or regressed deploy can serve the old launch-prep copy without failing the lane. The live site still serves the June-20 bundle, and all eleven shared-footer paths carry the old line. Add section E: every live path with the shared footer block must name the actual products (Promptly, Drishti) and must avoid every launch-prep fragment, using the same coverage and markers as the repo-side guard (scripts/test-public-footer-copy.mjs). Runs only in the release lane after a Pages deploy; not wired into npm test/ci. verify: node --check scripts/check-public-live-deploy.mjs; live run detects the stale launch-prep copy on all 11 paths (118 failures = stale bundle, same pre-token state as sections A-D)
![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: 26 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 (1)
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: 5c99578c42
ℹ️ 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 fragment of LAUNCH_PREP_FRAGMENTS) { | ||
| ok(!copy.includes(fragment), `${label} footer copy avoids "${fragment}"`) |
There was a problem hiding this comment.
If a deployed footer contains a capitalization variant such as Before launch or Gives each product, every negative assertion passes because String.prototype.includes is case-sensitive, even though the launch-prep copy this acceptance check is intended to reject is still live. Normalize the extracted footer copy and fragments to a common case, or use case-insensitive expressions, so capitalization-only edits cannot produce a false-green deployment.
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.
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: e30daceeea
ℹ️ 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 checkFooter = (label, html) => { | ||
| const footer = footerBlockOf(html) | ||
| ok(footer.length > 0, `${label} has a footer block`) | ||
| const copyBlock = footer.match(/<p class="footer-copy"[^>]*>([\s\S]*?)<\/p>/) |
There was a problem hiding this comment.
When a shared footer remains semantically unchanged but its attributes are reordered, use single quotes, or add another class (for example, <p style="..." class="footer-copy">), this regex fails to recognize the paragraph and blocks the post-deploy release lane. Match the class attribute regardless of attribute order and quoting, or parse the footer as HTML, so valid markup refactors do not produce a false deployment failure.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
…-copy-guard # Conflicts: # scripts/check-public-live-deploy.mjs
|
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.
Comment-block conflict only in check-public-live-deploy.mjs: keep main every managed-service snooze review disposition alongside this branch new proof note.
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. |
PR #123 landed its own section E (Cloudflare email obfuscation) in check-public-live-deploy.mjs. Kept both live checks and relabelled this branch section from E to F.
|
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.
|
Rebased during the backlog sweep, then knocked back into conflict again — this is a structural issue with the cluster, not a problem with this PR. What happened. Five PRs each append a new lettered proof section to the same function in Effort to land: small but strictly serial. The conflict is one hunk, always the same shape — keep Suggested order so each PR is rebased exactly once: #110, then #97, then #154, then #118. Landing them back to back is much cheaper than landing them days apart. Nothing here is stale — this branch's check is real, absent from |
check-public-live-deploy.mjs now carries sections A-G on main (E Cloudflare email #123, F JSON-LD #127, G footer tap-targets #110). Rather than resolve the overlapping hunks by hand, this takes main file verbatim and grafts this branch shared-footer copy proof onto it as section H. Repo check chain green.
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. |
|
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
What
Adds section E to
scripts/check-public-live-deploy.mjs(the release-lane live acceptance): every live path carrying the shared footer block must name the actual products (Promptly, Drishti) and must avoid every launch-prep fragment, using the same coverage and markers as the repo-side guard.Why
The tracked finding "Eleven public pages still end with launch-prep footer copy ('gives each product a clean public foundation before launch')" is real on the live site: tinystudio.in still serves the June-20 bundle, and all eleven shared-footer paths (plus the served 404) carry the old line. The repo-side fix (PR #35) is merged on
main, but the deploy-path acceptance never verified the footer copy — so a stale or regressed deploy can serve launch-prep copy without failing the lane. This closes that live-layer blind spot per the "fix the instance AND the detector" rule.Checks added (44)
For each of the eleven shared-footer paths and the served 404 (same paths as the repo guard):
.footer-copyparagraph existsRuns only in the release lane after a Pages deploy (same contract as sections A–D); not wired into
npm test/ci, so CI stays green while the site waits on the Pages token.Verification
node --check scripts/check-public-live-deploy.mjs→ OKNote
The live site cannot leave the June-20 bundle until a Cloudflare Pages-scoped token is provisioned (one-time dashboard step documented in
scripts/publish-public-site.mjs); this PR makes the lane prove the footer copy is gone after that deploy instead of trusting it.