Skip to content

docs: correct stale PR-body-sync wording in process-hardening and testing docs - #1855

Merged
BigSimmo merged 9 commits into
mainfrom
claude/content-deletion-pr-issues-lq2xhv
Aug 12, 2026
Merged

docs: correct stale PR-body-sync wording in process-hardening and testing docs#1855
BigSimmo merged 9 commits into
mainfrom
claude/content-deletion-pr-issues-lq2xhv

Conversation

@BigSimmo

Copy link
Copy Markdown
Owner

Summary

  • docs/process-hardening.md and docs/testing.md still described the CI sync-pr-policy-body gate as firing whenever PR_POLICY_BODY.md was merely present on the checked-out PR head. That was the actual bug (ledger #230, fixed in af8e717): an inherited copy of that scratch file — e.g. carried forward by a routine git merge origin/main — could trip the sync and silently overwrite an unrelated PR's real description with stale scratch content.
  • The gate itself was already fixed (pr_policy_body_changed now derives from the PR's own diff, not filesystem presence, and is covered by a dedicated regression self-test in scripts/ci-change-scope.mjs that runs in required CI). This PR only updates the two doc sentences that still described the old, incorrect behavior, and adds a pointer to #230 in docs/testing.md for future readers.

Verification

  • npx prettier --check docs/process-hardening.md docs/testing.md — passed ("All matched files use Prettier code style!")
  • Verification not run: npm run verify:pr-local / verify:ui / verify:release — doc-comment-only change with no source, config, or behavior touched; not applicable per the verification pyramid's Tier 1 (documentation/comments) guidance.

Risk and rollout

  • Risk: None — comment/prose wording only, no source or CI behavior change.
  • Rollback: Revert this commit.
  • Provider or production effects: None

Notes

  • No RAG impact: or ## Clinical Governance Preflight section is required — this PR does not touch src/lib/rag/**, retrieval/ranking, ingestion, answer generation, or any clinical-output surface.

Generated by Claude Code

process-hardening.md and testing.md still described the pr_policy_body
CI gate as firing on file *presence*, which was the bug fixed in
af8e717 (#230 — an inherited PR_POLICY_BODY.md from a main merge could
overwrite an unrelated PR's description). The gate now checks the PR's
own diff.
@supabase

supabaseBot commented Aug 12, 2026

Copy link
Copy Markdown

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.


Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

@coderabbitai

coderabbitaiBot commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in:41 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: ce67ff8f-b43e-4c1d-a0b3-a97e23f43507

📥 Commits

Reviewing files that changed from the base of the PR and between cac49ac and bf12504.

📒 Files selected for processing (2)
  • docs/process-hardening.md
  • docs/testing.md

Comment @coderabbitai help to get the list of available commands.

@BigSimmo
BigSimmo enabled auto-merge August 12, 2026 14:45
@BigSimmo
BigSimmo disabled auto-merge August 12, 2026 17:29
@BigSimmo
BigSimmo requested a lite review from CopilotAugust 12, 2026 19:30
@BigSimmo
BigSimmo enabled auto-merge August 12, 2026 19:30
@BigSimmo
BigSimmo merged commit c0dec59 into mainAug 12, 2026
26 checks passed
@BigSimmo
BigSimmo deleted the claude/content-deletion-pr-issues-lq2xhv branch August 12, 2026 19:32

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates documentation to match the already-shipped CI behavior for PR body synchronization, preventing confusion about when sync-pr-policy-body runs.

Changes:

  • Clarifies in docs/testing.md that PR body sync is gated on the PR’s diff changing PR_POLICY_BODY.md, not mere filesystem presence (and notes the inherited-file pitfall).
  • Updates docs/process-hardening.md to match the same corrected gating condition.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

FileDescription
docs/testing.mdUpdates CI-topology wording for PR body sync gating; adds a reference to the regression tracked as #230.
docs/process-hardening.mdCorrects the process-hardening summary sentence to reflect diff-based gating for PR body sync.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment threaddocs/testing.md
UI scope runs a fail-fast `@critical` Chromium job on pull requests / merge queues, then required production Chromium journeys (`test:e2e:pr:shard`) across three **duration-aware explicit file groups** (`scripts/playwright-pr-shards.mjs`). Those later groups exclude `@critical`; main, scheduled, and ordinary manual runs skip the fail-fast job and retain the complete set. The dated per-file timing profile is the single source for membership and keeps both full and post-critical estimates within 30 seconds; filesystem/config parity tests fail closed on orphans, duplicates, or matcher drift. Cross-job webpack-cache transport is deliberately absent after the merged PR's final run moved a 1.09 GB artifact three times for no critical-path benefit. `.github/actions/setup-ui-e2e/**` is UI-scoped so changing the browser environment exercises its owner. `src/app/api/**` does not set `ui_changed` or `db_changed` — API handlers stay on unit/coverage (and offline RAG when retrieval-scoped). The `PR required` aggregate keeps `if: always()` and distinguishes `cancelled` from `failure` in its messages. `release-browser-matrix` runs on UI/performance/lockfile-relevant `main` pushes and on every release-branch, ordinary manual, and scheduled run; its Playwright wrapper owns the isolated production build, and successful in-run production Chromium leaves only Chromium mockups plus Firefox/WebKit. Missing prior Chromium proof falls back to the full matrix. The Lighthouse-baseline refresh dispatch is a focused measurement operation rather than a synthetic full run. Container scope calls the reusable Docker workflow and requires both app and worker image builds through the aggregate.

PR body synchronization is skipped unless the checked-out head actually contains `PR_POLICY_BODY.md`. The eval-canary liveness API probe runs once with the daily Ops Digest cadence rather than on every PR. These remove repeated provider-side work without weakening a required result.
PR body synchronization is skipped unless the current PR's own diff changes `PR_POLICY_BODY.md` — an inherited copy merely present on the checked-out head (e.g. from a `main` merge) no longer triggers it (`#230`). The eval-canary liveness API probe runs once with the daily Ops Digest cadence rather than on every PR. These remove repeated provider-side work without weakening a required result.
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@BigSimmo@claude