Expand description
The redaction engine (SPEC §8.2) — the SECOND line of defense behind the never-log-at-source rule
(SPEC §7). Applied to every line at BUNDLE time (bundle::build re-redacts the
on-disk JSONL as it is zipped) so a log bundle is safe to hand to a stranger. It is NOT applied at
write time — the on-disk log files hold RAW lines, and logs tail/a manual copy therefore see
un-redacted text. The primary defense is source-discipline (SPEC §7, the never-log list); bundle
redaction is the guaranteed chokepoint for anything sent off-box. The rule set is VERSIONED
(RULES_VERSION) and recorded in every bundle manifest, so a bundle’s redaction guarantees are
auditable after the fact.
A false negative ships a secret, so the detectors err toward over-redaction — with ONE deliberate
exception: key detection is FIELD-NAME-driven, never a blanket “32-byte hex = secret” heuristic,
because storeIds, rootHashes, coinIds, puzzle hashes, and peer IPs are ALSO high-entropy hex/base64
and are KEPT (they are public and load-bearing for debugging, SPEC §8.2). A field whose NAME marks
it secret (*_key/*_secret/sk/xprv/wif/seed/mnemonic/…) has its value redacted; a
field on the known-safe list ([SAFE_KEY_NAMES]) is always kept even when its name ends _key
(e.g. resource_key). The mnemonic detector matches a run of ≥12 consecutive BIP39-wordlist words
regardless of whether they sit in key=value, a bare # Mnemonic: comment line, a numbered
1. abandon 2. ability … layout, or a \n-escaped multi-line value — the .test-credentials
leak (2026-07-12) proved that comment-style seeds are the real hazard. Non-English BIP39 wordlists
are an accepted residual (English-only), documented in SPEC §8.2.
Constants§
- RULES_
VERSION - The versioned redaction rule set. Bump on any rule change; recorded in the bundle manifest.