feat(checks): warn when --allow-existing-red runs against a stale local base #70
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "agent/checks-stale-base-warn"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Defect-2a stale-base detection in
--allow-existing-redclassification.cargoless checks run --base <ref> --allow-existing-rednow warns when thelocal tracking ref is behind real origin before re-running checks against
the base worktree. Without the warning, a stale
origin/devsilently resolvesto a pre-PYAML merge-base and
classify_required_reds_at_basereports phantomcounts for whole-tree fingerprint checks — the wedge PYAML hit on donut
(~5 false-block dev-merge attempts).
What's in this PR
base_freshness_warning()inBaseWorktree::create— uses read-onlygit ls-remote origin <short>to compare local tracking-ref tip vs realorigin. Warns when they differ; classification proceeds regardless.
rev-list --countsucceeding (objects in odb),warn only if drift ≥
CARGOLESS_BASE_STALE_THRESHOLD(default 5).When count fails (the common stale-clone case — objects not in odb), warn
regardless, because the user is reasoning against a base they cannot even
fully describe locally.
stale_base_testscovering: happy path silent, theexact production wedge (objects unavailable → "unknown number of commits"),
count-known path, threshold honoured, unresolvable base silent.
CARGOLESS_BASE_STALE_CHECK=0.CI
All 4 jobs green on the final commit
1051126: build / test / fmt / clippy.ra-bench correctly skipped (S1 harness).
Commit history (will squash)
8b48840feat(checks): warn when classify-at-base runs against a stale local tracking refcb63c72fix(checks): clippy clean stale-base helper1051126fix(checks): rustfmt edition-2024 single-line if-else`cargoless checks run --base <ref> --allow-existing-red` re-runs project checks against a base worktree to classify required reds as inherited vs. new. When the local `origin/<ref>` lags real origin, the base worktree resolves to a pre-merge-base tree and whole-tree fingerprint checks report phantom diagnostic counts — classifications come back as "new" because their fingerprints don't match the stale-base run. This is the wedge the PYAML team hit on donut (~5 false-block dev-merge attempts, reported as Defect 2 in 2026-06-23 ticket). `BaseWorktree::create` now calls a read-only `git ls-remote origin refs/heads/<ref>` before `git worktree add` and compares the remote tip to the local tracking ref. When tips differ: - if `rev-list --count` succeeds (remote objects are in odb), warn when drift ≥ CARGOLESS_BASE_STALE_THRESHOLD (default 5); - if `rev-list --count` fails (the common stale-clone case), warn regardless — the operator is reasoning against a base they cannot even fully describe locally. Disable with CARGOLESS_BASE_STALE_CHECK=0. Detect-only: the warning suggests `git fetch origin <ref>`; classification continues regardless, so this never blocks a build. `ls-remote` never advances local refs. Unit tests use a file:// origin fixture to exercise: silent-when-fresh, warn-when-objects-missing (the wedge case), warn-with-count-when-objects- available, threshold-honoured-when-count-known, silent-for-unresolvable-base. Belongs alongside the existing A1–A4 asks in tf-multiverse/.docs-discovery/plan/cargoless-source-asks.md as A5. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>`cargo fmt --check` (workspace edition 2024) collapses `if x.is_empty() { None } else { Some(name) }` onto one line. My earlier `rustfmt <file>` (no flag) defaulted to edition 2015 which expands them to 5 lines — fmt CI oncb63c72caught the drift. Re-formatted with `rustfmt --edition 2024` so the source matches what CI checks. No behaviour change. Clippy/build/test all stayed green oncb63c72; only fmt was red. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>