Skip to content

fix: pin the dolt scan directory; stop reporting infrastructure failure as "item not found" - #70

Merged
Brian Krabach (bkrabach) merged 2 commits into
mainfrom
lane/8zv-dolt-scan-dir
Sep 3, 2026
Merged

fix: pin the dolt scan directory; stop reporting infrastructure failure as "item not found"#70
Brian Krabach (bkrabach) merged 2 commits into
mainfrom
lane/8zv-dolt-scan-dir

Conversation

@bkrabach

Copy link
Copy Markdown
Collaborator

Pin the dolt scan directory; stop reporting infrastructure failure as "item not found"

Fixes model_performance-8zv. Diagnosis is lane model_performance-rpz's
(ai-notes branch lane/rpz-dolt-error-misreport, a6c6e03); this PR fixes,
measures, and fences it. $0 spend — no API calls, no DTU, no infrastructure.

Full lane note: docs/lanes/8zv-dolt-scan-dir/DONE-NOTE.md.
Raw evidence: docs/lanes/8zv-dolt-scan-dir/evidence/.

The defect

The dolt CLI enumerates its data directory and lstat()s every entry on every
invocation — including the pure client mode (--host/--port against the already-running
shared server) that every _dolt_* helper uses, where no local database is relevant.
With no --data-dir, that directory is the inherited cwd — whatever directory the
calling agent happened to be in. If an entry vanishes between readdir and lstat,
dolt aborts the whole query. So the failure rate of a work-tracker read was set by an
unrelated process's litter in /tmp.

Past that, three sites flattened the failure into a claim about the data:

site measured lie
claim_item "item not found" for an item that exists — 9 of 12
get_readonly bare "item 'X' not found in project 'Y'", cause discarded2 of 8, against an item the session HELD
project_summary healthy project printed as ERROR with null counts — 5 of 10

get_readonly is the worst: it is the exact path context/awareness.md hazard #6 tells
agents to trust as the safe recovery after an ambiguous write.

The change

  1. Remove it. _dolt_scan_dir() — a stable, empty, memoised directory we own —
    applied two independent ways: cwd= on the hot helpers, and --data-dir in
    _dolt_conn_args() so every dolt invocation gets it by construction.
  2. Retry it. _run_dolt_sql_bounded() gives the direct-SQL path (19 unretried call
    sites) the same bounded transport retry Beads._run already had for bd;
    "failed to load database names" joins _RETRYABLE_CONNECTION.
  3. Stop lying past the budget. BeadsUnavailableError makes "unreachable" a type,
    not a substring callers must grep. claim_item/get_readonly re-raise it untouched;
    project_summary reports UNAVAILABLE: …, distinct from both ok and ERROR.
  4. Fence it. New doctor assumption read.unavailable_not_absent, both directions.

CLI/web follow-on: instances prints the new status verbatim; the dashboard paints an
unreachable project amber Unavailable, not crimson Broken.

Measurement — rpz's harness, run verbatim, raw counts

RUN A — stock installed CLI (0.1.0, unfixed)
  0. empty cwd 0m0.056s ; /tmp (66292 entries) 0m8.685s
  2. raw dolt, cwd = churning dir (today's code path)  failures:  7 / 25
  3. FIX A -- cwd pinned to a stable dir               failures:  0 / 25
  4. FIX B -- cwd churning, --data-dir pinned          failures:  0 / 25
  5. list --id <an item this session HOLDS>: 7 of 8 attempts denied its existence

RUN B — LANE build (fix applied), shimmed first on PATH
  0. empty cwd 0m0.036s ; /tmp (66292 entries) 0m0.873s
  2. raw dolt, cwd = churning dir (today's code path)  failures: 12 / 25
  3. FIX A -- cwd pinned to a stable dir               failures:  0 / 25
  4. FIX B -- cwd churning, --data-dir pinned          failures:  0 / 25
  5. list --id <same item>: 8 of 8 attempts returned the real record

25/25 succeed with the scan directory pinned, by either remedy, in both runs.
Run B's load was harsher (12/25 raw failures vs 7/25), so the fixed CLI was not merely
luckier. The item predicted 6/25 unpinned; measured today it is 7/25 and 12/25 — same
defect, worse rate (this host's /tmp grew from 52,281 to 66,292 entries). Stated rather
than smoothed.

Captures: .amplifier/evaluation/treatment-validation/2026-09-02-model_performance-8zv/.

The no-blurring guardrail

A fix that makes every "not found" say "maybe transient" replaces one lie with another.
Every transient-failure test here is paired with a healthy-database test asserting the
absence wording is unchanged — one of them byte for byte. The three CLI-tier
guardrails pass on the parent commit and on this branch. That is the point of them.

Fail-before

New tests run against the parent (2468a69, src/ reverted, tests kept) —
docs/lanes/8zv-dolt-scan-dir/evidence/fail-before.txt:

unit : 18 failed, 2 passed
cli  :  3 failed, 3 passed

The passes are exactly the unchanged-behaviour guardrails.

Tiers — all four, by name, plus the modules tier

Tier Result
make test-unit 810 passed
make test-integration 322 passed, 3 skipped (14:00)
make test-cli 86 passed, 1 failed — pre-existing test_doctor_quick_succeeds_against_the_real_installed_bd (model_performance-jyg)
make test-ledger 24 passed
modules/tool-work-tracker/tests 100 passed, 1 failed — pre-existing test_explicit_resolve_refusal_after_reap_… (model_performance-c0e)
make check clean; pyright 0 errors
doctor All 35 assumptions hold

jyg was checked, not assumed: its failing line is [FAIL] sweeps.alive — no heartbeat ever recorded…, and the new read.unavailable_not_absent reports [PASS] inside that
same run. doctor's 35 is measured, not computed; AGENTS.md updated in all three
places carrying the old count.

@bkrabach
Brian Krabach (bkrabach) marked this pull request as ready for review September 3, 2026 06:47
@bkrabach

Copy link
Copy Markdown
Collaborator Author

Manager verification (independent, scratch clone)

Verified in a fresh clone at PR head 20557bc5bde2f3983615f30494234bf71510dba1;
merge-base = origin/main tip 2468a69, fast-forwardable.

Classification: FIX. Three read paths report infrastructure unavailable as
item absent — including list --id, which context/awareness.md hazard #6
tells agents to trust as the safe recovery read. Merging.

The failure is actually removed, not tolerated — measured end to end

Beyond the unit tests, I drove the fixed helper directly from a 20,000-entry
working directory:

PINNED _dolt_sql_json from a 20k-entry cwd -> returncode 0, elapsed 0.086s
  args: ['dolt', '--data-dir', '~/.cache/amplifier-work-tracker/dolt-scan',
         '--host', '127.0.0.1', '--port', '3308', '--no-tls', 'sql', ...]
scan dir: ~/.cache/amplifier-work-tracker/dolt-scan   entries: 0

The directory dolt enumerates is now a stable one holding zero entries, so
there is nothing to vanish between readdir and lstat. Belt and braces are
both present and both correct: cwd= on the two hot helpers and --data-dir
on every invocation via _dolt_conn_args, so a call site added later cannot
silently reintroduce the inherited-cwd scan.

Fail-before, reproduced

New tests at parent 2468a69 with the parent's own src/ pinned on
PYTHONPATH
— without that pin the editable install resolves the PR's source
and everything passes, which is a false negative worth naming:

18 failed, 2 passed

…including test_claim_item_under_transport_failure_does_not_say_item_not_found
and test_project_summary_under_transport_failure_is_UNAVAILABLE_not_ERROR.

The no-blurring guardrail is real, not asserted.
test_claim_item_genuine_absence_is_UNCHANGED and
test_project_summary_real_read_failure_still_reports_ERROR are in that same
fail-before set and pass on the head — so a genuine 404 on a healthy database
still reports absence, and this change has not replaced one lie with another.
That was the deliverable most easily satisfied dishonestly, and it wasn't.

All tiers

tier result
unit 809 passed, 1 flake ↓
integration 322 passed, 3 skipped (14:16)
cli 86 passed, 1 failed ← pre-existing (jyg)
ledger 24 passed
modules 100 passed, 1 failed ← pre-existing (c0e)
ruff check / format clean, 147 files
doctor All 35 assumptions hold — matches this PR's AGENTS.md claim exactly

The AGENTS.md count was measured, not computed — 35, read off doctor on
this tree. Good; last cycle the arithmetic answer would have been wrong.

tests/unit/test_supervisor_web.py is a port-binding flake, characterised, not
waved past
: this cycle it failed 3 of 5 whole-file runs on the PR head and 1 of
4 at the parent, the identity of the failing test varies between
serves_https and omits_trust_bootstrap, and it passes 14/14 when the file is
rerun. It fails on trees that do not contain this PR, so it is not a regression
here. It deserves its own item.

Scope

16 files: adapter.py (scan-dir pin + a bounded retry for the direct-SQL path +
BeadsUnavailableError), cli.py, contract.py, webapp.py, webbrowse.py,
their tests, AGENTS.md, and the lane's own docs/lanes/8zv-dolt-scan-dir/.
Nothing outside the diagnosis.

The type-based distinction is the right call over a substring callers must grep:
except BeadsUnavailableError re-raises the transient case cause-intact, and
project_summary reports UNAVAILABLE: … — a third vocabulary word between
ok and ERROR, which is what instances was missing.

Squash + --admin (plain squash refused by this repo's base-branch review
policy, as with #67/#58/#49/#350 this batch).

@bkrabach
Brian Krabach (bkrabach) marked this pull request as draft September 3, 2026 06:49
@bkrabach

Copy link
Copy Markdown
Collaborator Author

Manager: NOT merging — CI is red, and this PR is the cause. Back to draft.

Everything in my verification comment above still holds: the fix is real, the
fail-before reproduces (18 failed at parent), all five local tiers pass modulo
two genuinely pre-existing failures, and the scan-dir pin measurably works.
But CI's test job fails on this head, and it fails because of this PR.

FAILED tests/cli/test_cli_surface.py::test_doctor_quick_succeeds_against_the_real_installed_bd
  AssertionError: command printed error-looking text but exited 0
  (this is exactly the silent-failure shape amplifier-work-tracker shipped before)
1 failed, 86 passed

Root cause — one word

tests/_util.py:

_ERROR_WORD_RE = re.compile(r"\berror\b", re.IGNORECASE)

doctor --quick prints every assumption's description. This PR's new
assumption description is:

"…and reports UNAVAILABLE (not ERROR) per project, while genuine absence
on a healthy database still reports plain 'not found'"

\berror\b matches ERROR at offset 125. doctor exits 0 in a healthy
environment, so assert_no_silent_failure fires. Verified directly:

>>> _util.looks_like_error_text(<the new description>)
True
>>> _util._ERROR_WORD_RE.search(...)
<re.Match span=(125, 130), match='ERROR'>

Why neither the lane nor my first pass caught it — worth knowing

This is the same test that already has an unrelated pre-existing failure
(model_performance-jyg). Locally it dies at the earlier assertion:

assert result.returncode == 0      # jyg: isolated root has no sweep heartbeat

…so the run never reaches assert_no_silent_failure, and the new failure is
invisible on every local run. On CI the sweep environment is healthy,
doctor exits 0, execution proceeds to the third assertion, and the new failure
appears. Two different failures wearing the same test name — which is exactly
why "same test that was already failing" was a reasonable-looking call and was
still wrong. I recorded it as pre-existing in my comment above; that was my
error, corrected here.

What it needs

Reword the description to avoid a bare error token — note "not an ERROR row",
"error-row status" etc. all still match \berror\b. Something like "reports
UNAVAILABLE per project rather than the failure status a healthy project used to
get"
works. Then re-push; CI should go green and I will merge.

The bigger finding, filed separately

assert_no_silent_failure makes any assumption description containing the
word "error" a CI failure
, in a catalogue whose entire subject matter is error
handling. That is a landmine for every future assumption, and rewording this one
description does not disarm it. Filed as model_performance-8ba — the check
should scope itself to emitted error output rather than the command's own
descriptive text.

No other gate failed. This is a one-line prose change away from merging.

@bkrabach

Copy link
Copy Markdown
Collaborator Author

Correction to the comment above: the follow-up item filed for the underlying trap is model_performance-wp6 (I wrote 8ba before the id was assigned). Same content: assert_no_silent_failure's \berror\b regex reads doctor's own assumption DESCRIPTIONS as emitted error output, in a catalogue whose subject matter is error handling — so the trap re-arms for the next assumption even after this PR's sentence is reworded.

Brian Krabach (bkrabach) pushed a commit that referenced this pull request Sep 3, 2026
`assert_no_silent_failure` used a bare `\berror\b`, which is a test for
the word appearing rather than for an error being emitted. `doctor` prints
every assumption's own DESCRIPTION on a healthy run, so in a catalogue whose
subject is error handling one honest sentence turns a green run red --
`read.unavailable_not_absent`'s "... reports UNAVAILABLE (not ERROR) per
project ..." matched at offset 125 and failed
test_doctor_quick_succeeds_against_the_real_installed_bd on a completely
healthy system, blocking PR #70.

Replaced with five announcement shapes, each justified by output this
project actually emits: `error:` (the shipped `reap` bug, adapter's
`ERROR: <cause>` project status, gateway's `ERROR: tokens file...`,
argparse's `prog: error: msg`), a JSON `"error": <non-empty>` field
(supervisor writes one into printed payloads), `error running`,
`unknown command`, and a Python `Traceback`. The last two are NEW
coverage -- neither contains the word "error" at all.

tests/unit/test_error_announcement_detection.py pins both directions in one
file: the innocent case (PR #70's real description text) and the guilty one
(`Error: unknown command "reclaim"` with exit 0 still raises).
Brian Krabach (bkrabach) pushed a commit that referenced this pull request Sep 3, 2026
Brian Krabach (bkrabach) added a commit that referenced this pull request Sep 3, 2026
…#70) (#74)

* test(_util): match error ANNOUNCEMENTS, not the word "error"

`assert_no_silent_failure` used a bare `\berror\b`, which is a test for
the word appearing rather than for an error being emitted. `doctor` prints
every assumption's own DESCRIPTION on a healthy run, so in a catalogue whose
subject is error handling one honest sentence turns a green run red --
`read.unavailable_not_absent`'s "... reports UNAVAILABLE (not ERROR) per
project ..." matched at offset 125 and failed
test_doctor_quick_succeeds_against_the_real_installed_bd on a completely
healthy system, blocking PR #70.

Replaced with five announcement shapes, each justified by output this
project actually emits: `error:` (the shipped `reap` bug, adapter's
`ERROR: <cause>` project status, gateway's `ERROR: tokens file...`,
argparse's `prog: error: msg`), a JSON `"error": <non-empty>` field
(supervisor writes one into printed payloads), `error running`,
`unknown command`, and a Python `Traceback`. The last two are NEW
coverage -- neither contains the word "error" at all.

tests/unit/test_error_announcement_detection.py pins both directions in one
file: the innocent case (PR #70's real description text) and the guilty one
(`Error: unknown command "reclaim"` with exit 0 still raises).

* docs(lane wp6): DONE-NOTE + fail-before, tier, and #70 evidence under the lane artifact root

---------

Co-authored-by: amplifier-lane <lane@localhost>
…re as "item not found"

Root cause (measured by lane model_performance-rpz, harness
probes/rpz-dolt-error-misreport/repro.sh): the `dolt` CLI enumerates its
data directory and lstat()s every entry on EVERY invocation -- including
pure client mode against the already-running shared server -- and with no
--data-dir given that directory is the INHERITED cwd of whatever agent
happened to call us. If an entry vanishes between readdir and lstat, dolt
aborts the whole query. Same query, same server: 0.031s from a 2-entry
cwd, 0.805s from /tmp (52,281 entries). Under a churning 40k-entry
directory: 6 failures in 25 attempts.

1. REMOVE the failure. `_dolt_scan_dir()` -- a stable, empty, memoised
   directory we own -- is applied two independent ways, each measured at
   0/25 under the same load: `cwd=` on the two hot helpers, and
   `--data-dir` via `_dolt_conn_args` so every dolt invocation in the
   module gets it by construction.

2. RETRY it. The retry classification lived only in `Beads._run` (which
   wraps `bd`); the direct dolt-SQL path had none, across 19 call sites.
   `_run_dolt_sql_bounded` gives it the same bounded transport retry, and
   "failed to load database names" joins `_RETRYABLE_CONNECTION`.

3. STOP LYING past the budget. `BeadsUnavailableError` makes
   "infrastructure unreachable" structurally distinct from "not found" --
   a TYPE, not a substring callers must grep. `claim_item` (9 of 12
   measured attempts said "item not found" about an item that existed) and
   `get_readonly` (2 of 8 denied an item the session HELD, discarding the
   cause entirely) re-raise it untouched. `project_summary` reports
   `UNAVAILABLE: ...`, distinct from both `ok` and `ERROR` (5 of 10
   attempts printed a healthy project as ERROR with null counts).

4. FENCE it. New contract assumption `read.unavailable_not_absent` checks
   BOTH directions -- and genuine absence on a healthy database still
   reports absence in exactly the same words, because a fix that makes
   every "not found" say "maybe transient" is a second lie. `doctor` now
   measures 35/35 (read off doctor, not computed); AGENTS.md updated in
   both places.
@bkrabach
Brian Krabach (bkrabach) marked this pull request as ready for review September 3, 2026 10:44
@bkrabach

Copy link
Copy Markdown
Collaborator Author

Manager: rebased onto 802c204wp6 has landed, so the blocker is gone. Head a097365.

model_performance-wp6 merged as 802c204: assert_no_silent_failure now matches error announcement shapes instead of a bare \berror\b, so this PR's read.unavailable_not_absent description no longer turns a healthy doctor run red. wp6's evidence tested that against this PR's own head (20557bc), not a synthetic fixture: parent predicate MATCHed at offset 302, the new predicate finds no announcement.

Two conflicts, both resolved by keeping BOTH sides — they were additive, not competing:

The count is MEASURED, not computed. doctor --quick on the rebased branch reports:

All 37 assumptions hold. Safe to run parallel agents.

37, not the 36 the merge left in the prose — so I patched both AGENTS.md sites to 37 and said in the file that it was measured on the rebased branch rather than derived from 36+1. (This is the third time in this batch that the arithmetic answer and the measured one differed; measuring keeps winning.)

Re-verified after the rebase: unit + ledger 859 passed, ruff check clean.

Locally test_doctor_quick_succeeds_against_the_real_installed_bd still fails here — but at the first assertion (returncode == 0), i.e. model_performance-jyg: this machine's sweep heartbeats live outside the isolated test root, so doctor exits 1 and execution never reaches assert_no_silent_failure. That is precisely the masking wp6's DONE-NOTE documents, and it is why CI — where the sweep environment is healthy — is the environment that actually settles this one. Watching CI now.

@bkrabach

Copy link
Copy Markdown
Collaborator Author

CI GREEN. test: COMPLETED:SUCCESS on a097365 — the first green CI this PR has had. wp6 (802c204) was the only thing standing between it and main, and the fix worked exactly as its evidence predicted.

Merging: FIX with a reproduced fail-before (18 failed at the parent with the parent's own src/ pinned), doctor 37/37 measured, and the scan-dir pin verified behaviourally from a 20,000-entry cwd (0.086s, --data-dir pinned to a 0-entry directory).

@bkrabach
Brian Krabach (bkrabach) merged commit 98dd223 into main Sep 3, 2026
2 checks passed
Brian Krabach (bkrabach) pushed a commit that referenced this pull request Sep 6, 2026
…he service does not serve

`_check_sweeps_alive` joined a SERVICE-scoped fact (`describe_service()` --
one singleton unit per user) to a ROOT-scoped one (a heartbeat file under
whichever workspace root `doctor` was pointed at). That join is only sound
when the two refer to the same root. Against any other root the heartbeat is
absent BY CONSTRUCTION, and the check reported that absence as "no heartbeat
ever recorded ... the loop may never have started" -- a hard FAIL, exit 1, on
a machine whose sweep loops were provably running fine.

Every isolated test root is such a root, so
tests/cli/test_cli_surface.py::test_doctor_quick_succeeds_against_the_real_
installed_bd failed on any developer machine whose service serves a real
workspace -- and, because `assert returncode == 0` came first, it MASKED
every later assertion in that test. Measured twice: model_performance-wp6
(announcement-predicate collision, invisible locally, CI-only, blocked PR #70
for days) and model_performance-kxk.

The assumption is right; it is simply not evaluable against a root the
supervisor was never given. `_serve_argv_tail` already bakes `--root` into
the unit as an explicit argument, so the served root is readable:
`ServiceInfo.served_root` reads it back (systemd ExecStart, launchd
ProgramArguments), and both sweep checks report `unknown` on a mismatch --
following the precedent `sweeps.reclaiming` set in model_performance-oy4
(46d7da4) for exactly this shape.

The FAIL path is untouched where it matters: against the SERVED root, a
missing, stale, or dead-pid heartbeat is still a loud failure, and a sweep
that failed on every project still fails `sweeps.reclaiming`. When the served
root cannot be determined at all, the checks evaluate the heartbeat anyway
and can still FAIL -- "cannot tell" must never become a way to make a real
dead-loop failure disappear.

Separately, the masking itself is fixed: the cli test now checks its three
properties independently and reports them together
(`_util.assert_doctor_run_is_clean`), so the next environmental exit-1 from
any cause cannot hide the next real defect. `assert_no_silent_failure` and
its announcement predicate are called unchanged.

doctor MEASURED at 38/38 (unchanged).
Brian Krabach (bkrabach) pushed a commit that referenced this pull request Sep 6, 2026
…he service does not serve

`_check_sweeps_alive` joined a SERVICE-scoped fact (`describe_service()` --
one singleton unit per user) to a ROOT-scoped one (a heartbeat file under
whichever workspace root `doctor` was pointed at). That join is only sound
when the two refer to the same root. Against any other root the heartbeat is
absent BY CONSTRUCTION, and the check reported that absence as "no heartbeat
ever recorded ... the loop may never have started" -- a hard FAIL, exit 1, on
a machine whose sweep loops were provably running fine.

Every isolated test root is such a root, so
tests/cli/test_cli_surface.py::test_doctor_quick_succeeds_against_the_real_
installed_bd failed on any developer machine whose service serves a real
workspace -- and, because `assert returncode == 0` came first, it MASKED
every later assertion in that test. Measured twice: model_performance-wp6
(announcement-predicate collision, invisible locally, CI-only, blocked PR #70
for days) and model_performance-kxk.

The assumption is right; it is simply not evaluable against a root the
supervisor was never given. `_serve_argv_tail` already bakes `--root` into
the unit as an explicit argument, so the served root is readable:
`ServiceInfo.served_root` reads it back (systemd ExecStart, launchd
ProgramArguments), and both sweep checks report `unknown` on a mismatch --
following the precedent `sweeps.reclaiming` set in model_performance-oy4
(46d7da4) for exactly this shape.

The FAIL path is untouched where it matters: against the SERVED root, a
missing, stale, or dead-pid heartbeat is still a loud failure, and a sweep
that failed on every project still fails `sweeps.reclaiming`. When the served
root cannot be determined at all, the checks evaluate the heartbeat anyway
and can still FAIL -- "cannot tell" must never become a way to make a real
dead-loop failure disappear.

Separately, the masking itself is fixed: the cli test now checks its three
properties independently and reports them together
(`_util.assert_doctor_run_is_clean`), so the next environmental exit-1 from
any cause cannot hide the next real defect. `assert_no_silent_failure` and
its announcement predicate are called unchanged.

doctor MEASURED at 38/38 (unchanged).
Brian Krabach (bkrabach) added a commit that referenced this pull request Sep 6, 2026
… service does not serve (model_performance-jyg) (#77)

* fix(doctor): `sweeps.alive` reports `unknown`, not FAIL, for a root the service does not serve

`_check_sweeps_alive` joined a SERVICE-scoped fact (`describe_service()` --
one singleton unit per user) to a ROOT-scoped one (a heartbeat file under
whichever workspace root `doctor` was pointed at). That join is only sound
when the two refer to the same root. Against any other root the heartbeat is
absent BY CONSTRUCTION, and the check reported that absence as "no heartbeat
ever recorded ... the loop may never have started" -- a hard FAIL, exit 1, on
a machine whose sweep loops were provably running fine.

Every isolated test root is such a root, so
tests/cli/test_cli_surface.py::test_doctor_quick_succeeds_against_the_real_
installed_bd failed on any developer machine whose service serves a real
workspace -- and, because `assert returncode == 0` came first, it MASKED
every later assertion in that test. Measured twice: model_performance-wp6
(announcement-predicate collision, invisible locally, CI-only, blocked PR #70
for days) and model_performance-kxk.

The assumption is right; it is simply not evaluable against a root the
supervisor was never given. `_serve_argv_tail` already bakes `--root` into
the unit as an explicit argument, so the served root is readable:
`ServiceInfo.served_root` reads it back (systemd ExecStart, launchd
ProgramArguments), and both sweep checks report `unknown` on a mismatch --
following the precedent `sweeps.reclaiming` set in model_performance-oy4
(46d7da4) for exactly this shape.

The FAIL path is untouched where it matters: against the SERVED root, a
missing, stale, or dead-pid heartbeat is still a loud failure, and a sweep
that failed on every project still fails `sweeps.reclaiming`. When the served
root cannot be determined at all, the checks evaluate the heartbeat anyway
and can still FAIL -- "cannot tell" must never become a way to make a real
dead-loop failure disappear.

Separately, the masking itself is fixed: the cli test now checks its three
properties independently and reports them together
(`_util.assert_doctor_run_is_clean`), so the next environmental exit-1 from
any cause cannot hide the next real defect. `assert_no_silent_failure` and
its announcement predicate are called unchanged.

doctor MEASURED at 38/38 (unchanged).

* docs(lane jyg): DONE-NOTE + before/after evidence (doctor MEASURED 38/38; five tiers green)

---------

Co-authored-by: Amplifier <240397093+microsoft-amplifier@users.noreply.github.com>
@bkrabach
Brian Krabach (bkrabach) deleted the lane/8zv-dolt-scan-dir branch September 6, 2026 02:34
Sign up for free to 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.

2 participants