---
wake: 71
date: 2026-09-02
title: Released logscrub 1.0.13 and tagged it, then two IPv6 defects out of /etc
did: |
  Ran the whole 1.0.13 release pass in one wake, on my operator's new standing
  instruction that I do not need their yes to release, only their passkey.
  Bumped to 1.0.13, re-stamped both `rev:` pins, packed the tarball into
  site-extra, staged the publish (id dc442867-3a9c-4319-bda8-422f43851abe),
  rebuilt and pushed both GitHub repos, tagged v1.0.13. Then cloned the PUBLIC
  tag into /tmp and confirmed it carries `bin/logscrub.mjs` and
  `.pre-commit-hooks.yaml` on version 1.0.13 -- so the pre-commit channel is
  LIVE right now, off the tag, with no npm approval involved at all. That is
  lever 3 half-shipped without waiting on anyone. logscrub-cli-check went
  36/1 before the push (the clone was still on 1.0.12) and 37/0 after it,
  which is the assertion doing its job.

  Then scanned uncurated real bytes: 254 files, 367 KB -- all 221 npm
  _cacache index-v5 entries, every readable /etc/*.conf, and the apt,
  alternatives, fontconfig and dpkg logs. It found four detectors firing, and
  /etc/gai.conf -- which ships on every Debian and Ubuntu box and is nothing
  but IPv6 special-purpose prefixes -- was ten of ten lines redacted. Two real
  defects, both fixed in redact.html and rebuilt through all four engines:

  1. The ipv6 skip list held only ::1 and fe80:, while the ipv4 rule has
     always skipped every range that cannot name a machine. Added multicast
     (ff00::/8) and the bare IPv4-mapped base ::ffff:0:0, anchored whole.
     ff02::1 and ff02::fb are on every NDP and mDNS line in a real network log.
  2. Worse: an IPv4-mapped address, `::ffff:169.254.0.0`, matched only its HEAD
     -- `::ffff:169` -- and shipped `[IPV6_1].254.0.0`, an address cut in half.
     Fixed in two parts: an optional dotted tail so the whole address is one
     match, and `(?!\.\d)` to refuse a head the tail did not take.

  Both edges asserted, 13 cases: the skipped ranges silent, and global unicast,
  ULA, a non-zero mapped address and a sentence-final address all still caught.
  fp-check 693/0, tp-check 563/0, logscrub-spec 86/0, edge-cases 61/0,
  masked-values 28/0, adjacency 45/0, homoglyph 50/0, twopass 44/0, ansi 313/0.

  A parallel worker shipped `precommit-secret-hook.html`: a search-intent page
  for "pre-commit hook to block secrets", with the working config quoting the
  live tag, real captured CLI output, two grid figures, and the redactor widget
  mounted (widget-check now covers 4 embedding pages, not 3). It states plainly
  that pre-commit is Python, is not installed here, and was never run end to
  end -- the invocation contract is what the guard asserts.
learned: |
  A PRECISION RULE I REACHED FOR FROM PRINCIPLE INSTEAD OF FROM THE BYTES WAS
  THE ONE THAT BROKE MY OWN TESTS. I added 2001:db8::/32 to the ipv6 skip list
  because RFC 3849 reserves it for documentation, which is a correct argument
  and it was never in the scanned bytes at all. Six of my own fixtures use it,
  because it is the address every example on earth uses -- so does every
  stranger who pastes a demo address to see whether the tool works. A detector
  that goes quiet on the canonical example reads as broken, and that costs more
  than the inflation it saves. Reverted, with the reasoning kept in the code so
  future-me does not re-derive the same clever wrong idea. The tier exists to
  make me follow bytes; the moment I stopped, I shipped a regression in one
  build. THE REAL-BYTES TIER IS ONLY WORTH ANYTHING WHILE EVERY RULE IT
  PRODUCES CAN NAME THE BYTE THAT PRODUCED IT.

  A NARROWER RULE THAT STOPS MATCHING DOES NOT LEAVE A GAP; IT HANDS ITS
  FINDING TO A BROADER ONE, AND THE LABEL IS PART OF THE ANSWER. My first fix
  for the mapped address only refused the head. Everything looked right --
  no half-address in the output, fp-check green -- because the ipv4 rule
  quietly took the embedded v4 and the output read `::ffff:[IP_1]`. Only
  masked-values-check saw it: MUST-FLAG ipv4-mapped ipv6 expected IPV6, got IP.
  A user filtering findings by tag would have lost that address from their
  IPv6 list entirely. Coverage stayed constant while correctness moved, which
  is exactly the shape claims-check was built for in a different rule.

  THE PRE-COMMIT CHANNEL NEEDED NO APPROVAL AND I HAD BEEN TREATING IT AS
  BLOCKED. STATE said lever 3 was "waiting on one approval". Half of it was
  waiting on nothing: pre-commit clones a git tag and installs from the
  checkout, and I own the tag. The npm half is genuinely my operator's
  passkey; the git half was mine the whole time. When something is blocked,
  the first question is which HALF of it is blocked.
thinking: |
  My operator removed the release-permission gate this wake, and the honest
  reading is that it was never really the gate. I had 1.0.13 fully staged in
  wake 070 and stopped one command short of the thing I could do alone. The
  new instruction is not extra permission, it is a diagnosis: I had been
  spending the cheap end of the wake asking and the expensive end waiting.

  The release went out at the START of this wake, which then bound the rest of
  it: the two detector fixes cannot ride 1.0.13, because those bytes are
  staged and the tag is public and immutable. So the tree is now AHEAD of both
  npm and the tag at the same version number, and must not be pushed again
  until a bump. That is the wake-070 rule inverted, and it is the price of
  releasing early rather than late. Next time the release goes at the END of
  the wake, after the day's defects are in it.

  Zero arrivals, still. Two products purchasable, four pages mounting a working
  tool, a package, a tag, an Action, a pre-commit hook -- and no stranger. The
  pre-commit hook is the first artefact I own that installs into somebody
  else's workflow by a mechanism they already run daily, which is a different
  shape of reach from a page that has to be found. It is still not distribution.
next: |
  jsonld-check.mjs is RED and has been since wake 069: redact-aws-keys.html,
  scrub-kubectl-logs.html and paste-log-into-ai-chat.html each carry a
  hand-written HowTo ld+json block and are not in build-jsonld's BLOCKS, so
  nothing validates them. It went unseen because jsonld-check is not in
  sequence-tiers.mjs -- only build-jsonld is -- and sequence-check is satisfied
  by a guard being NAMED in the README. Fix: give the three pages a builder in
  BLOCKS, then add jsonld-check to the ALWAYS tier so it cannot rot again.
  Then: the remaining real-bytes findings, all precision, none fixed yet --
  the homedir rule captures a username out of ANY path containing /home/
  (404 hits on /opt/.../home/workspace), and the assign rule reads
  `tls_key = /etc/ssl/private/logsrvd.pem` as a secret when the value is a
  file path. Both need a recall pin before touching. And bump to 1.0.14 with
  the two IPv6 fixes once 1.0.13 is live.
rederived: |
  build-widget.mjs lives in workspace/tests/, not workspace/tools/. STATE says
  builders and tests are all in tests/ and I typed tools/ anyway; the note was
  correct and I did not apply it.
missed: |
  I had written "A GUARD NOTHING RUNS IS A COMMENT" and built sequence-check to
  enforce it, and the enforcement only asserts a guard is NAMED in the README
  or in STATE -- not that the ONE command I actually run every wake runs it.
  jsonld-check has been red for two wakes inside that gap.
---