fix(ci): pull_request.base.sha is stale on long-lived PRs, so every gate that computes a range from it silently inspects the wrong changeset

[rickylabs]

Resolution audit — 0.0.7 planning

The stale-base failure was real in the former two-dot code-quality.yml construct, but that
construct was fixed by #1403. A fresh audit at 01e0960494c95ce56eb35892c211a095eb13e6ed found no
remaining implementation work.

Workflow / construct	Audited behavior	Resolution
ci.yml changed files	BASE_SHA...HEAD_SHA, fetch-depth 0	merge-base semantics; safe
e2e-cli.yml changed files	BASE_SHA...HEAD_SHA, fetch-depth 0	merge-base semantics; safe
surface-diff.yml changed files	BASE_SHA...HEAD_SHA, fetch-depth 0	merge-base semantics; safe
pages.yml changed files	BASE_SHA...HEAD_SHA, fetch-depth 0	merge-base semantics; safe
fresh-ui-quality.yml changed files	BASE_SHA...HEAD_SHA, fetch-depth 0	merge-base semantics; safe
code-quality.yml changed source	.llm/tools/quality/changed-source-files.ts, three-dot	fixed by #1403; red-first stale/foreign fixture exists
ci.yml / e2e-cli.yml / pages.yml / fresh-ui-quality.yml base deno.json	git show BASE_SHA:deno.json	not a changed-file range; deliberate base-vs-head tasks-only classification that fails toward running

Acceptance criteria

• Every changed-file range consuming pull_request.base.sha uses merge-base/three-dot semantics.
• A stale base does not admit foreign already-merged files into the scanned changed-file set.
• surface-diff, Pages, Fresh UI, CI, E2E CLI, and code-quality consumers were audited separately.
• The remaining git show BASE_SHA:deno.json constructs are explicitly classified as conservative
  applicability checks, not changed-file scans.
• The affected two-dot code-quality construct and its red-first fixture are owned and completed by fix(quality): quality:gate is substantially uninformative — arch:check omits 20 of 36 publishable packages and quality:scan covers only packages/cli/src #1403.

Boundary

This issue is audit-completed and is not a 0.0.7 implementation barrier. Reopening requires a new
red-first fixture against a currently unsafe construct, not the already-repaired #1403 line.

Provenance

Originally filed from the 0.0.6 #1539 reproduction. Corrected by the 0.0.7 PLAN-EVAL consumer-by-consumer audit on 2026-08-13.

[rickylabs]

Correction — blast radius is one line, not five. Three of four audited sites are safe.

Filed by me with an overstated scope. The 0.0.6 internals lane found the distinguishing factor and
I verified it independently before amending this issue.

Two-dot versus three-dot is the whole story. In git diff, A...B means diff from the
merge-base of A and B to B. A stale BASE_SHA is therefore harmless in the three-dot form:
merge-base(stale_base, head) == merge-base(current_main, head), because a stale base is always a
former main commit and hence an ancestor. The three-dot form is self-healing against exactly the
failure this issue describes.

Verified on main:

surface-diff.yml:54    git diff --name-status -M "$BASE_SHA...$HEAD_SHA"   THREE-DOT — SAFE
ci.yml:142             git diff --name-status -M "$BASE_SHA...$HEAD_SHA"   THREE-DOT — SAFE
e2e-cli.yml:140        git diff --name-status -M "$BASE_SHA...$HEAD_SHA"   THREE-DOT — SAFE
code-quality.yml:39    git diff ... "$BASE" "$SHA" -- packages plugins      TWO-DOT  — AFFECTED
openhands-phase-eval.yml:126                                               already fixed by #1552

Proven empirically on the reproduction in the body above — same stale base, same head, same
pathspec, only the range form differs:

$ git diff --name-only --diff-filter=ACMR cd24e1679 2a4102600   -- packages plugins   → 9 files
$ git diff --name-only --diff-filter=ACMR cd24e1679...2a4102600 -- packages plugins   → 0 files
$ git merge-base cd24e1679 2a4102600                                                  → 01aa12b67

Nine foreign files versus zero. The two-dot form is the entire defect.

What changes in this issue

• surface-diff.yml is audited-safe, not affected. I flagged it as the correctness risk; that
  was wrong. Its step is even named "Compute changed files (merge-base diff, rename-aware)", which
  is accurate rather than aspirational. A stale base cannot make it report another PR's surface
  change or miss one of its own. Corroborated by a live case: PR fix(quality): stop scanning negative type fixtures as production source #1560's recorded base is
  f99cb4fbf while main is 59e435c5d — genuinely stale — and surface-diff passes correctly.
• ci.yml and e2e-cli.yml are audited-safe for the same reason.
• The remaining defect is code-quality.yml:39 alone, owned by fix(quality): quality:gate is substantially uninformative — arch:check omits 20 of 36 publishable packages and quality:scan covers only packages/cli/src #1403.

Revised acceptance

• code-quality.yml:39 computes its changed-file set with merge-base semantics (the three-dot
  form is a one-character change and needs no API call)
• Proven red-first: a branch cut from a stale base with one .llm/tools change asserts the
  scanned set equals that PR's own diff, not base..head
• The two further defects in the same five lines are covered by fix(quality): quality:gate is substantially uninformative — arch:check omits 20 of 36 publishable packages and quality:scan covers only packages/cli/src #1403: the pathspec
  -- packages plugins cannot admit .llm/tools/**, and an empty arg set skips the scan
  entirely while reporting success

Two valid fixes for this class now exist in-tree, and the choice depends on what the consumer needs:
resolve the base branch tip (#1552's approach — right when you need a specific trusted commit)
or use three-dot (right when you just need the PR's own diff). code-quality.yml wants the
latter.

Re-runnable audit

grep -nE 'git diff.*\$(BASE_SHA|\{\{)' .github/workflows/*.yml    # then check each for '...'

Leaving this issue open rather than closing into #1403: the audit result and the two-dot/three-dot
rule are worth keeping findable, and the grep above is the cheap recheck when a new workflow adds
a range computation.

[rickylabs]

Admitted to 0.0.7 Step 0 as release-critical under the milestone-cluster intake. The owner explicitly requested a pre-0.0.7 chase for CI false positives, and current main still derives path-classifier ranges from pull_request.base.sha in CI, E2E, docs Pages, Fresh UI, code-quality, and surface-diff workflows. This must land before the milestone relies on path-native skips as evidence. Coordinator: #1641; baseline: 01e0960494c95ce56eb35892c211a095eb13e6ed.