test(scope,executor): two tests took their precondition from the machine (#742)

[eaitbrahim]

Closes #742.

Two tests passed in CI and failed for any contributor with a configured deployment — the people most likely to run the suite locally.

FAILED tests/commands/test_scope.py::test_attest_writes_none_when_no_current_credential_resolves
FAILED tests/execution/test_executor.py::test_confirming_replaces_a_stale_fingerprint_rather_than_carrying_it_forward

The mechanism is sharper than "the environment leaks in"

CI's empty credential store was silently supplying a precondition one of the tests needed.

current_credential_fingerprint is imported independently at three sites — commands/scope.py, execution/guards.py (rails 20 and 22), and execution/executor.py. The executor test patches only its own. With a credential configured:

guards' copy resolves a genuine fingerprint → it disagrees with the row's "stale000…" → rail 20 vetoes the entry → execute never reaches the confirm step → the fingerprint stays stale and the assertion fails.

On CI the unpatched call returns None — "no evidence to disagree with" — no veto fires, and it passes. The None that made the test work came from the machine, not from the test.

The fix

Each test states its own assumption, in the pattern its own file already uses for every sibling test:

• test_scope.py patches keel.commands.scope.current_credential_fingerprint → None, exactly as the three tests above it already patch that same target. What's under test is what the command writes when nothing resolves; the "nothing resolves" half belongs in the fixture.
• test_executor.py patches both sites, deliberately to different values: guards → None so rail 20 has nothing to disagree with and the entry reaches the confirm step; executor → "fresh…" so the overwrite under test is observable. The asymmetry is written into the test, because a reader would otherwise "fix" it.

A suite-wide fixture was tried first, and is the wrong shape

Recorded because the idea is tempting and the reasons it fails aren't obvious. Three attempts, three collisions:

attempt	broke	why
stub _from_keychain	1	made test_the_broken_keychain_test_is_not_vacuous vacuous — it calls that function directly to prove it reaches keyring.get_password
pin default_env_path	5	test_paper_equities_profile.py legitimately chdirs and writes its own .env for load_alpaca_secrets, which doesn't use read_secret at all
wrap read_secret for identifier names	12	test_credential_identity.py deliberately exercises real .env/keychain resolution using exactly those names

This suite tests credential resolution on purpose, in several places. A blanket "nothing resolves anywhere" fixture fights the tests that exist to exercise the thing it suppresses. That's why the fix is local — and why the issue's original diagnosis (which blamed read_secret's three tiers and proposed the fixture) is corrected in a comment there rather than left to mislead.

Verification

Run in the condition that was broken — the full suite from the repo root with a real .env present:

6151 passed, 3 skipped in 218.36s

ruff check clean · mypy clean (441 files). Tests only; no library code, no config, no shipped parameter.

Left open deliberately

Three import sites resolving ambient credentials independently is a shape that will catch someone again. That's a design question, not a test bug, and it deserves its own issue rather than being smuggled into this one.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EXz13qp1UM3pBa6BqsRqvC