Conversation
…loy path repair) The live site has served the 2026-06-20 bundle (07acd07) since June 20 while 17+ public PRs merged to main; the Cloudflare Pages git connection for tiny-studio-3f5 never shows checks/statuses on commits and no deploy workflow or secrets exist in the repo. The fleet Workers token lacks Cloudflare Pages:Edit, so no automation on this box can publish today. Add an in-repo release lane that works the moment a Pages-scoped token is provisioned (documented fail-closed message): - scripts/prepare-public-deploy-bundle.mjs: filtered bundle (public/ minus the snoozed-by-Nish managed-service buyer path from PRs #10/#11; every other merged fix preserved), fail-closed in both directions - scripts/test-public-deploy-bundle.mjs: regression guard, wired into npm test/ci (62 checks) - scripts/publish-public-site.mjs: prepare -> wrangler pages deploy to tiny-studio-3f5 -> live verification - scripts/check-public-live-deploy.mjs: live proof for the deploy-path accept (H2-after-H1 /promptly/support/ #18/#20, JSON-LD /contact/ #19, real 404s #34, homepage portfolio-only #29 + no buyer path) - .github/workflows/deploy-public-site.yml: vps-verify lane on push to main - wrangler 4.120.0 devDependency verify: npm test (603 checks, 0 failures); node scripts/prepare-public-deploy-bundle.mjs; git diff --check
wrangler pages deploy accepts --commit-hash/--commit-message/--commit-dirty for dashboard provenance. The bundle already records source_commit in deploy-manifest.json; pass it through so the Pages dashboard links the deployment to the exact tinystudio-in commit that produced the bundle. verify: node --check scripts/publish-public-site.mjs; node scripts/test-public-deploy-bundle.mjs (62 checks, 0 failures) Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
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: 23 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 ignored due to path filters (1)
📒 Files selected for processing (6)
Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2e61eced79
ℹ️ 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".
| - uses: actions/setup-node@v7 | ||
| with: | ||
| node-version: 20 |
There was a problem hiding this comment.
The deploy job explicitly selects Node 20, but the newly locked wrangler@4.120.0 declares node >=22.0.0 in package-lock.json:1458-1480. Because npm ci normally only warns about an engine mismatch, the workflow can reach the publishing step and then invoke Wrangler on an unsupported runtime, preventing the production repair from deploying; use Node 22+ here or pin a Wrangler release that supports Node 20.
Useful? React with 👍 / 👎.
| on: | ||
| push: | ||
| branches: | ||
| - main | ||
| workflow_dispatch: |
There was a problem hiding this comment.
When workflow_dispatch is started from a non-main ref, checkout uses that selected ref, while publish-public-site.mjs:78 still passes --branch main to the Pages direct upload. That allows unmerged content from the selected branch to be promoted as a main/production deployment, and its ref-specific concurrency group can run alongside the real main deployment; validate github.ref == 'refs/heads/main' for this job or otherwise avoid labeling arbitrary dispatched refs as main.
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: 78217c3b8b
ℹ️ 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: "promptly/support H2 after H1 (PRs #18/#20)", | ||
| file: "promptly/support/index.html", | ||
| test: (html) => /<h1\b[^>]*>[\s\S]*?<\/h1>[\s\S]*?<h2\b/i.test(html), |
There was a problem hiding this comment.
When promptly/support/index.html has the stale H1 → H3 → H2 outline described by this change, this regex still passes because it merely finds any H2 after the closing H1. The pre-deploy heading test also omits this page from AFFECTED_PAGES (scripts/test-public-heading-hierarchy.mjs:20-26), so the workflow can upload the regression and detect it only during the post-deployment live check; apply the same first-H2-before-first-H3 ordering check while preparing the bundle.
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: a5b6782db9
ℹ️ 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".
| ok(body.includes("<title>Tiny Studio | Promptly, Drishti, and 0509"), "portfolio title is live") | ||
| ok(body.includes('"alternateName"'), "brand-disambiguation JSON-LD is live (PR #29)") | ||
| ok(body.includes("not affiliated"), "non-affiliation copy is live (PR #29)") |
There was a problem hiding this comment.
After one successful deployment, these static markers will also exist in every older deployment produced by this lane. If a later Wrangler upload succeeds but the custom domain continues serving that previous deployment, every live check can pass and the workflow reports the new merge as published even though it is absent; fetch the bundled deploy-manifest.json and compare its source_commit with the commit being deployed.
Useful? React with 👍 / 👎.
| for (const rel of REQUIRED_FILES) { | ||
| const p = join(bundleDir, rel) | ||
| if (!existsSync(p)) continue | ||
| const html = readFileSync(p, "utf8") |
There was a problem hiding this comment.
When a future public page or asset is added without also being added to REQUIRED_FILES, fs.cp includes it in the deployment but this loop never checks it for the snoozed buyer-path markers. The advertised fail-closed filter can therefore publish forbidden content from any newly added file; enumerate the copied bundle recursively rather than using the fixed required-file list.
Useful? React with 👍 / 👎.
| const get = async (path, { redirect = "manual" } = {}) => { | ||
| const res = await fetch(`${BASE}${path}`, { redirect }) | ||
| return { status: res.status, body: await res.text() } |
There was a problem hiding this comment.
If tinystudio.in accepts a connection but stalls while returning headers or the body, Node's fetch has no default request timeout, so this post-publish step can occupy the self-hosted runner until GitHub's job limit and, with cancel-in-progress: false, queue subsequent production deployments behind it. Pass an abort signal with a bounded timeout so a network stall fails promptly.
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: a6c2b43a3d
ℹ️ 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 failures = [] | ||
| for (const rel of REQUIRED_FILES) { | ||
| const p = join(bundleDir, rel) | ||
| if (!existsSync(p)) continue |
There was a problem hiding this comment.
When site:publish or site:publish:check is run directly after a required non-proof asset such as 404.html or styles.css is absent, this branch silently skips it. Those CLI paths do not run test-public-deploy-bundle.mjs, so preparation reports success and full mode can publish an incomplete site; add a failure for every missing REQUIRED_FILES entry instead of continuing.
Useful? React with 👍 / 👎.
…-heading finding The 2026-08-08 scout item named /promptly/support/: it was repaired in source by PR #20 (H1 -> H2 cards, no outline jumps) and origin/main already carries the fixed outline, but the live site still serves the June-20 bundle: the deployed page jumps H1 -> H3 (live 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 local suite (test-public-heading-hierarchy.mjs) did not even assert public/promptly/support/index.html, and the live heading-hierarchy guard from PR #76 checks Drishti support and Privacy Choices but not the scout's own page. Add /promptly/support/ to the local suite's affected pages (50 checks, 0 failures) and add scripts/test-public-live-heading-hierarchy.mjs guarding /promptly/support/ plus the two pages PR #76 covers, wired into npm test and npm run ci. Network-tolerant: skips when the site is unreachable, fails loudly while it serves the stale bundle. Once the release lane (PR #70) publishes the fixed bundle, the guard flips green. Publishing from this box is still blocked: the fleet Cloudflare token returns 403 on the Pages projects API (no Pages:Edit), and no Pages-scoped secret or wrangler exists here. intended-outcome: the Promptly support heading hierarchy can no longer regress silently on the live site; the stale June-20 deployment fails npm test/ci loudly until the fixed bundle is published. verify: node scripts/test-public-heading-hierarchy.mjs 50 checks 0 failures; node scripts/test-public-live-heading-hierarchy.mjs fails loudly on the current deployment (25 checks, 14 failures, all stale-deployment detections); npm test otherwise clean; find scripts -name '*.mjs' node --check clean; git diff --check clean
…-heading finding The 2026-08-08 scout item named /promptly/support/: it was repaired in source by PR #20 (H1 -> H2 cards, no outline jumps) and origin/main already carries the fixed outline, but the live site still serves the June-20 bundle: the deployed page jumps H1 -> H3 (live 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 local suite (test-public-heading-hierarchy.mjs) did not even assert public/promptly/support/index.html, and the live heading-hierarchy guard from PR #76 checks Drishti support and Privacy Choices but not the scout's own page. Add /promptly/support/ to the local suite's affected pages (50 checks, 0 failures) and add scripts/test-public-live-heading-hierarchy.mjs guarding /promptly/support/ plus the two pages PR #76 covers, wired into npm test and npm run ci. Network-tolerant: skips when the site is unreachable, fails loudly while it serves the stale bundle. Once the release lane (PR #70) publishes the fixed bundle, the guard flips green. Publishing from this box is still blocked: the fleet Cloudflare token returns 403 on the Pages projects API (no Pages:Edit), and no Pages-scoped secret or wrangler exists here. intended-outcome: the Promptly support heading hierarchy can no longer regress silently on the live site; the stale June-20 deployment fails npm test/ci loudly until the fixed bundle is published. verify: node scripts/test-public-heading-hierarchy.mjs 50 checks 0 failures; node scripts/test-public-live-heading-hierarchy.mjs fails loudly on the current deployment (25 checks, 14 failures, all stale-deployment detections); npm test otherwise clean; find scripts -name '*.mjs' node --check clean; git diff --check clean
|
Closing as a zombie PR — superseded by #81 (merged 2026-08-11, 45ef63b). #81 landed the tinystudio.in release lane this PR proposed: |
Problem
tinystudio.in has served the 2026-06-20 bundle since June 20 while 17+ public PRs merged to main. The Cloudflare Pages git integration for
tiny-studio-3f5never shows checks on commits, and the fleet Workers token lacks Cloudflare Pages:Edit — so nothing publishes the merged fixes.Today the live site still fails the release lane's own acceptance proofs (verified 2026-08-11):
/promptly/support/renders H1 → H3 → H3 → H3 → H2 (H2-after-H1 fix fix(public): repair heading hierarchy on audited pages #18/fix(public): restore Promptly support heading hierarchy #20 not live)/contact/has noapplication/ld+json(structured data feat: add truthful public page structured data #19 not live)alternateName/ "not affiliated" copy (brand disambiguation fix(public): disambiguate Tiny Studio from unrelated tiny studio brands #29 not live)What
scripts/prepare-public-deploy-bundle.mjs— filtered bundle frompublic/, snoozed managed-service buyer path (feat(public): route founders to reviewed Website Correction #10/feat(measurement): add Website Correction conversion signal #11) removed, every other merged fix preservedscripts/test-public-deploy-bundle.mjs— 62-check regression guard, wired intonpm test/CIscripts/publish-public-site.mjs— prepare → wrangler direct upload totiny-studio-3f5→ live verification; passes the source commit through as deployment provenancescripts/check-public-live-deploy.mjs— 13 live proofs of the neutral merged fixes.github/workflows/deploy-public-site.yml— runs on push to main and manual dispatchCLOUDFLARE_API_TOKEN+CLOUDFLARE_ACCOUNT_IDrepo secrets, and the next main merge publishes.Verify
node scripts/test-public-deploy-bundle.mjs— 62 checks, 0 failuresnode scripts/prepare-public-deploy-bundle.mjs— bundle contains H2-after-H1, JSON-LD, real 404, portfolio homepage; buyer path absentnode scripts/check-public-live-deploy.mjs— currently 6/13 failures, which is exactly the gap this lane closes once secrets existNote: repo has no
CLOUDFLARE_*secrets yet; the lane is fail-closed until provisioned.