D-26 requires `make test` to pass with no network; T-55's audit measured 426
passed/29 skipped with network vs. 412 passed/23 skipped/20 ERRORS inside an
unprivileged network namespace. All 20 errors trace to a real Bolt connection
opened at fixture setup (neo4j_client -> client.connect()), not to test logic.
The ticket's own summary said all 20 were in test_entity_linking.py; tracing
the actual error list showed only 5 were (TestEntityLinkingIntegration,
TestEntityLinkingMultiTenancy, plus the trailing module-level cleanup test).
The other 15 are every test in test_hybrid_rag.py, whose hybrid_rag_service
fixture resolves graph_service -> neo4j_client regardless of what the test
body itself exercises -- including the RRF-fusion and context-formatting
classes that read as pure logic. There is no unit/integration split inside
that file without restructuring its fixture graph, which is out of scope
here; the whole module is marked instead of picking classes apart from
underneath a shared fixture chain.
The fix is the mechanism this repo already had and had never wired to a
target: tests/conftest.py's `integration` pytest marker plus its
RUN_INTEGRATION_TESTS/TEST_TENANT gate (test_integration.py,
test_tenant_isolation_live.py, test_quality_report_live.py and
TestWikiChangeListenerIntegration already used it). Applying the same marker
here means `make test` skips these 20 the same way it already skipped the
other 23 -- no file move, no new fixture layer, matching repo precedent
exactly rather than inventing a second convention beside it.
`make test-integration` is the D-26 home: sets RUN_INTEGRATION_TESTS=1,
selects `-m integration`, and treats pytest's own "no tests collected" exit
code (5) as a hard failure rather than a pass, so a marker that gets renamed
or lost fails loudly instead of the target quietly collecting zero and going
green.
Verified (unshare -rn sh -c 'ip link set lo up; ...' after confirming the
positive control -- a live :8089 returning HTTP 200 outside returns curl exit
7 inside):
make test, no network: 412 passed, 43 skipped, exit 0 (was 20 ERRORS)
make test, with network: 412 passed, 43 skipped, exit 0 (unchanged; the 14
of these 20 that were previously counted in the 426 passed now skip by
default -- reclassified, not lost; the other 6 already skipped for an
unrelated reason before this change)
make test-integration, these 20, with network: 14 passed, 6 skipped
(test_wiki_page's own pytest.skip when it can't create a wiki page -- a
pre-existing soft-skip, unrelated to this change), 0 failed, exit 0
make test-integration mutated to select a nonexistent marker: FAIL,
"selected 0 tests", exit 2 -- confirmed loud, then reverted
Not fixed here: the other 23 tests already carrying `integration` include
three files (test_integration.py, test_tenant_isolation_live.py,
test_quality_report_live.py) that fail under `make test-integration` today
because they call the local dev server on :8778, which was not running in
this session -- a pre-existing "never proven runnable" gap this same ticket
family exists to find, but a different set of tests than the one measured
here.
Co-Authored-By: Claude <noreply@anthropic.com>
`make setup` exited 0 whether or not the environment it produced was
usable — per D-24, a step whose job is to not fail has a passing state
indistinguishable from its broken state. Adds two cheap checks at the
end: `pip check` for version drift between installed packages, and
`pytest --collect-only` to walk the full src/ import graph and catch a
missing declared dependency, which is what core-api's undetected
missing sqlalchemy looked like (T-47). Neither needs any of the five
backing services running — dependencies.py only constructs clients
inside lru_cache getters, never at import/collection time.
Also fixes `setup` to install requirements-dev.txt rather than
requirements.txt. It only ever installed the latter since the
Makefile's introduction, so `make test` and `make lint` — both of
which need pytest and ruff — were never actually reachable from a
clean `make setup`. requirements-dev.txt pulls in requirements.txt via
-r, so the runtime set installed is unchanged; only the tooling to
prove it is added. Found because the new check failed honestly on its
first clean-tree run, before this fix.
Verified: clean-tree run installs everything and passes (455 tests
collected); a second run is a fast no-op; uninstalling a declared
runtime dependency (asyncpg) makes the check fail with
ModuleNotFoundError, and rerunning setup restores and re-passes it.
Co-Authored-By: Claude <noreply@anthropic.com>
The hook carried ~50 lines of gitleaks logic and a comment explaining it was
self-contained because "this repo has no Makefile". It has one now, so the
reason is gone and the arrangement is backwards: a hook is a trigger, and
logic belongs where it can be read, run by hand, and changed under review.
.githooks/pre-push is now a byte-identical shim onto `make pre-push` in every
repo in the workspace. The scan itself moves to ci/secrets.sh unchanged, and
`make secrets` runs it on its own.
The call surface is identical everywhere; what it runs is not, and should not
be — each repo gates what it actually has. That is the point of standardising
the name rather than the contents: nobody has to read a repo to find out how
to check it.
secrets runs first, deliberately. It is the only failure here that cannot be
undone by fixing it afterwards — a failed lint costs another commit, a pushed
credential is cached and indexed whether or not it is later deleted.
Some of these gates fail today, on lint debt that predates them, and they are
left wired anyway. The board was measured once and written down in T-56
instead of being worked around here. Narrowing each gate to whatever already
passes would produce a gate that reports success for doing nothing, which is
the failure this workspace keeps rediscovering.
Co-Authored-By: Claude <noreply@anthropic.com>
Environment guards now exit 69 rather than 1, so a caller can tell a suite
that could not start from one that ran and failed. The first toj test sweep
reported "3 repositories failed" and none of the three had executed a test —
two could not find go, one had no venv. That points the reader at the tests
when the fault is in the environment.
Only the environment guards change. A gitleaks finding, a failed test run and
a vulncheck hit still exit 1, because those did run and did fail.
Co-Authored-By: Claude <noreply@anthropic.com>
Every repo gets one at the root: help, plus test and lint where those exist.
The point is that a target name means the same thing in every repo, so an
agent or a person can act without reading the repo first.
Paths resolve here rather than in callers (D-10). python3 on this host is 3.8
and cannot parse these sources, and a bare pytest or ruff resolves only in a
login shell — so both are named explicitly through the venv, and a missing
venv fails with the command to fix it rather than a bare no-such-file.
Co-Authored-By: Claude <noreply@anthropic.com>
jpmschweitzerandClaude