A redaction placeholder became a primary key, and it closed other people's promises

Two failures came out of the same substitution, and they do not deserve equal weight. The unclosable liability is loud: the ledger opened `promises:health:token-redacted`, no `[done]` citing the real slug could ever bind that key, and the tool was still reporting finished work as leaked six hours later ^[8]. That one is visible and can be repaired by hand. The collision is the one that matters, because the placeholder is the same string on every line from every author, so separate obligations land in one account and a single `[done]` nets the row to zero ^[3].

In the reproduction, two owners held two tasks sharing one key and only one of them filed a `[done]`; `mesh-promises --report` printed no leaked promises, `0/0/0/0 open`, one kept ^[4]. One obligation was genuinely outstanding and the report accounted for none of it, so the open count was wrong by the entire quantity it exists to measure ^[13]. The author's observation about the merged row is the transferable part: it looks exactly like one healthy row, so the anonymisation removed the evidence that anything had been anonymised ^[9].

The mechanism is stated plainly in the post. A redaction function returns a constant, and a constant is never an identity, so a masked field that reaches a key, a fingerprint, a cache key or a `GROUP BY` turns the masker into an equality operator asserting that everything it could not read is the same thing ^[10]. The author gives two other shapes it takes: an error tracker that fingerprints on a message containing a scrubbed user ID merges unrelated crashes into one issue, and resolving that issue resolves all of them ^[14]; a pipeline that rewrites `user_id` to a fixed `<REDACTED>` whenever a value fails validation makes every such user the same user, with `COUNT(DISTINCT user)` reporting one ^[15].

The repair the post calls obvious, teaching the catch-all that this particular string is an identifier, had already been attempted three times, for a review slug, a git SHA and a filename, and each widened alphabet left the next case redacted, because "long, high-entropy, no prefix" describes secrets and identifiers equally well ^[11]. What worked instead was refusing to look at the token at all: the log's grammar fixes the slug's position, immediately after `[task]`, `[taking]`, `[verify]`, `[done]` or `[chat-review]`, after a `chat-review/` prefix, or after the close-key `task:`, and a token in that slot is an identifier by construction whatever its shape ^[2]. The guarantee is bounded by that enumeration, so a slug quoted in prose, or one written under a verb added later, is back to being judged on entropy.

Scope matters here. This is one machine, one person's scrubber and a homegrown double-entry ledger, with the author stating that every number, listing and command output was re-measured while writing ^[12]. The bug class is the finding, not the tool. The question it hands everyone else is narrower than a policy review: where does your masker sit relative to the first thing downstream that parses what it wrote.