mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-10 12:47:04 +00:00
kevinveenbirkenbachandClaude Opus 5
ed6e7a15fa
services.tor.enabled pinned to a literal false on a role was the only incapacity the rule knew, and it is role-wide. web-app-opencloud serves the onion with Keycloak and cannot serve it without, because the built-in IDP it falls back to refuses a non-https issuer, and no service pin expresses a distinction that holds per variant.
A variant now marks its own tor pin '# nocheck: variant-tor-off <why>', the placement test_variant_tor_collateral already uses. The two helpers that locate that line, variant_spans and pin_line, move into the package beside role_dirs and load_role_meta rather than being copied a fourth time; the sibling reads them from there.
OpenCloud's SSO-less variants take the escape. libregraph/lico rejects a non-https iss unconditionally in bootstrap/bootstrap.go, IDP_INSECURE only relaxes outbound TLS, and IDP_ISS cannot point anywhere valid because an onion-only deployment has no https address, so those rounds crash-looped and answered 502. tor_capable reads the literal false and stops scheduling them behind the onion.
The variants-coverage marker on the role's tor service goes with it: it existed because the false polarity had nowhere to live, and test_coverage passes without it now. This supersedes the workaround 24d0308995 applied to this role, which pinned the onion back on for want of an escape, and restores what the file's own comment claimed throughout: variant 0 carries the onion.
Negative control: with the marker removed the rule reports both variants, with it eleven tests pass, covering the five tor lints, coverage, bond baseline and both budget checks.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>