test_stele_router_mount failure — characterization note — v0.1Version. 0.1 Date. 2026-07-18 Author. Claude Code on DUNIN7-M4. Status. Characterization only. NOT fixed. Queued as a post-Stage-1 investigation by Operator ruling. Filed with. The dunin7.com perimeter Stage 1 documents.
One engine test fails. It is not caused by the perimeter Stage 1 work — that was established by reverting both repositories to baseline and restoring the original .env, where it still fails. It matters enough to write down for two reasons: the engine's recorded baseline is zero failures, so something regressed it before this session; and the failure is in session resolution, which is the same machinery a real passkey sign-in depends on.
The evidence says this is a test-harness problem, not a production defect — but the root cause is not yet identified, and one earlier hypothesis was tested and disproved, so this note stops short of naming a cause.
tests/test_stele_router_mount.py::test_stele_router_mounts_and_begin_resolves_end_to_end
AssertionError: {"detail":"Authentication required (no valid session)."}
assert 401 == 200
tests/test_stele_router_mount.py:139
The test seeds a principal with one passkey, mints a session token with issue_session(..., totp_verified=True, secret_key=TEST_SECRET_KEY), sets it as the session cookie, and posts to /me/security/passkeys/begin expecting 200. It gets 401.
Reproduced with both repositories stashed to baseline (loomworks-engine and stele) and .env reverted to its pre-Stage-1 values (WEBAUTHN_RP_ORIGIN=https://loomworks-dev.dunin7.com, no WEBAUTHN_ADDITIONAL_ORIGINS, no LOOMWORKS_SESSION_COOKIE_SECURE). The failure persists in that state.
This check was worth doing carefully: an earlier, sloppier attempt at a "baseline" was invalid because .env is gitignored, so git stash does not revert it, and because a cd persisted across a command and stashed the wrong repository. Both were caught and redone.
The decisive evidence: tests/test_me_security.py passes 21/21. It exercises the same /me/security/* routes, including the same passkey-enrollment surface, through the standard api_client fixture against the real application.
test_stele_router_mount is the only test that builds a bespoke bare FastAPI app (_build_mounted_app) and hand-wires the Stele injection slots. Same routes, same session machinery: passing through the real app, failing through the bespoke mount. That isolates the difference to the mount harness's app construction.
Corroborating: real sign-in at loomworks-dev.dunin7.com works today, which a genuine session-resolution break would not permit.
The natural first guess was that the test overrides Stele's provide_secret_key slot but not the engine's own get_secret_key, so get_current_principal would validate against settings.loomworks_secret_key from .env (a different key from TEST_SECRET_KEY) and reject the token.
This is wrong. The test overrides both:
tests/test_stele_router_mount.py:94 — ov[engine_deps.get_db_session] = _yield_dbtests/test_stele_router_mount.py:95 — ov[engine_deps.get_secret_key] = _secret_keyRecorded because it is the most tempting explanation and it does not hold.
Offered as starting points, not conclusions:
require_fresh_session on mutation routes, and TS-16 added CSRF double-submit. POST /me/security/passkeys/begin is a mutation route, and the test sends only a session cookie. Either could reject the request, though neither obviously produces this specific "no valid session" wording.
Step 5 performs an actual passkey ceremony at https://app.dunin7.com. If this failure reflects a genuine session-resolution defect, that ceremony fails. If, as judged here, it is harness wiring, the ceremony succeeds while this test keeps failing.
Step 5's result is therefore evidence either way, and should be recorded against this note.
A full passkey ceremony completed at https://app.dunin7.com, and the authenticated caller resolved through the same-origin proxy to {"level":"founder","rank":3}.
This is decisive rather than suggestive. The session cookie is written without a domain= attribute, so it is host-only: a session established at loomworks-dev.dunin7.com is never sent to app.dunin7.com. For that authenticated response to exist at the new host, the ceremony must have completed there — driving the same session-resolution machinery this test fails on, at a freshly configured origin.
Conclusion: the failure is confined to that test's bespoke mount harness. Production session resolution is sound. The investigation remains queued, but it is a test-correctness item, not a security or availability item, and should be prioritized accordingly.
DUNIN7 — Done In Seven LLC — Miami, Florida
Loomworks — test_stele_router_mount failure — characterization note — v0_1 — 2026-07-18