All notes
Architecture

The redaction that never redacted

Janus's documented path-redaction layer was dead code: the orchestrator never passed repoPath, so the `<repo>` substitution never fired despite living in code and docs. A data-egress guard needs a test that asserts the sensitive token is actually gone from the output.

Janus has a documented privacy layer that rewrites absolute repo paths to a <repo> placeholder before sending pulse prompts to the LLM. It turned out that substitution had been dead code since the layer shipped: the orchestrator never passed project.repoPath as the second argument to resolveRunner(), so paths only ever collapsed to ~ and the <repo> redaction never fired. The fix (bdd770d) wired project.repoPath through src/pipeline/orchestrator.ts, making the redaction live for the first time.

Present in the code is not the same as running

The redaction function existed. It was referenced in the docs. It was correct in isolation. None of that mattered, because a single argument was never passed at the one call site that would have activated it. A feature can be fully written, documented, and reviewed, and still be inert — the gap between “the code exists” and “the code runs on real input” is exactly one un-passed argument wide, and nothing about reading the function reveals it.

A guard is only as real as the token it removes

The failure mode here is specific to data-egress guards: the system kept working. Pulses generated, prompts sent, output looked fine — because collapsing paths to ~ is itself a plausible, partial redaction. The absence of the stronger <repo> substitution was invisible from the outside. A privacy layer that half-works is more dangerous than one that crashes, because nothing signals that the sensitive token is still leaking into every prompt.

Test the output, not the guard’s existence

The lesson generalizes to any redaction, masking, or scrubbing layer: the test must assert on the output — the sensitive token is gone from the string that leaves the process — not merely that the guard function is defined or gets called. Had a test rendered a prompt for a project with a real repoPath and grepped the result for that absolute path, the dead substitution would have failed loudly on day one instead of shipping silent. For a data-egress guard, the assertion is the feature. Everything else is scaffolding around a claim no one checked.