docs: file the signal-pager and triage findingsHEADmain

Nine tasks filed, from four senders and my own work. Two are [#A]: the triage github-prs precondition passes on a work credential, so a personal sweep returns work PRs, and the pager receive timer on ratio, which is now fixed.

Three of the filings are one bug wearing different clothes. A guard that can't tell "nothing to do" from "couldn't do it" reports success either way. It showed up in the receive timer, in the triage engine, and in a test that went green at exit 127 against a path that didn't exist. Worth fixing as a class rather than three times.

1 files changed, 337 insertions, 0 deletions

diff --git a/todo.org b/todo.org
index 3213a6f..07e2ad6 100644
--- a/todo.org
+++ b/todo.org
@@ -39,6 +39,343 @@ Tags are assigned and refreshed by =task-audit=; =task-review= keeps them honest
 
 * Rulesets Open Work
 
+** TODO [#A] github-prs plugin returns work PRs into personal triage :bug:
+SCHEDULED: <2026-08-19 Wed>
+:PROPERTIES:
+:LAST_REVIEWED: 2026-08-19
+:END:
+=triage-intake.github-prs.org:15= gates on =command -v gh && gh auth status=.
+=gh auth status= exits 0 when *any* configured host authenticates, including a
+GitHub Enterprise host, so the precondition can pass on the strength of the work
+credential alone. The scan then runs =gh search prs --author=@me=, which resolves
+against the enterprise host and returns work PRs into a personal project's
+triage. home hit this today and discarded a =deepsat/sbir-pleo-d2p2-submission=
+PR by hand.
+
+Reproduced on velox:
+
+: gh auth status                              rc 0
+: gh auth status --hostname github.com        rc 1
+: gh auth status --hostname deepsat.ghe.com   rc 0
+
+So the precondition passes with no *usable* github.com credential, and every
+result would be work rather than merely some.
+
+home corrected one detail I had wrong. I first read this as github.com not being
+configured at all; the entry does exist, its token is simply invalid
+(=GH_HOST=github.com gh auth status= prints "The token in default is invalid").
+Same functional state and the same fix, but the entry's existence is what makes
+the failure quiet — gh knows the host, so nothing in the config looks absent.
+
+Fix needs both halves. Pin the precondition
+(=gh auth status --hostname github.com=) and pin the scan, because =gh search
+prs= has no =--hostname= flag — =GH_HOST=github.com= is the lever. The
+precondition alone only caught today's case because github.com's token happens
+to be broken; with two valid hosts it would pass and the scan would still be
+ambiguous.
+
+The plugin's own header says a work project on GHE declares its own plugin and
+does not edit this one, so github.com-only is the stated design. The defect is
+that nothing enforced it.
+
+*Generalize before closing:* an =:ENABLED:= test proving *a* credential exists is
+not the same as proving the *right* one does. Every plugin whose tool can address
+more than one account has this shape — audit the others rather than fixing this
+one in isolation.
+
+Grading: severity-alone carve-out. This is a confidentiality boundary violation —
+work material surfacing in a personal project, in a system whose boundary
+discipline exists to keep them apart — and it presents identically to a healthy
+scan. One occurrence with the wrong PR in it is a showstopper regardless of
+frequency, so Critical = P1 = =[#A]=. Source: home handoff 2026-08-19.
+
+** TODO [#B] triage-intake reports a clean close over an unactionable backlog :bug:
+:PROPERTIES:
+:LAST_REVIEWED: 2026-08-19
+:END:
+Two levels, and the engine half is the one that matters.
+
+*Plugin:* =triage-intake.personal-gmail.org:11= gates on the
+=google-docs-personal= MCP, and all three hygiene verbs (lines 73-75: trash,
+mark-read, star+read) are MCP-only. When that MCP is absent the source goes
+inactive and the sweep announces a skip — going blind on the highest-volume
+personal channel, which held 873 unread when home looked. The other Gmail MCP on
+offer is work-bound (there is a recorded 2026-07-23 incident where a pass used it
+expecting personal and got 201 unread work messages), so it is not a substitute.
+Confirmed absent from this velox session too.
+
+home worked around the *read* half by scanning the maildir through =mu=, which
+their notes already name as the reliable path when an MCP binding is in doubt —
+but the plugin does not sanction it, so that was their substitution rather than
+the workflow's. Fix: declare the mu/maildir fallback as a real scan tier and give
+it action verbs. =cmail-action.py= is the working model (local script over the
+maildir, with mark-read/star/trash); a =gmail-action.py= sibling closes it, and
+mbsync already syncs the maildir.
+
+*Engine, and this is the durable half:* =triage-intake.org= Phase D says hygiene
+runs on every scanned account. It has no concept of a source that was *scanned*
+but whose action verbs are unavailable, so the sweep classifies everything and
+acts on nothing while reporting a clean close. Today that gap surfaced only
+because home wrote a prose line about it. It should be a first-class close
+outcome alongside =SCAN FAILED= — e.g. =ACTIONS UNAVAILABLE: <source> — scanned
+via <fallback>, hygiene not run, N items left unprocessed=.
+
+*This is the third instance today of one failure shape:* a mechanism that cannot
+distinguish "nothing to do" from "could not do it" reports success either way.
+The others are the pager receive timer (=[#A]= above) and the reviewer's own
+bats variant that went green at exit 127. Worth fixing as a class, not three
+times.
+
+Grading: Major severity (the sweep reads but cannot act, and says nothing, so the
+backlog only grows and every later sweep re-reads it) x most sweeps, frequently =
+P2 = =[#B]=. Source: home handoff 2026-08-19.
+
+** DONE [#A] Pager receive timer was dead on ratio and reported success :bug:
+CLOSED: [2026-08-19 Wed]
+:PROPERTIES:
+:LAST_REVIEWED: 2026-08-19
+:END:
+Fixed and verified. =signal-receive.service= on ratio had been exiting
+=status=0/SUCCESS= every 15 minutes while receiving nothing.
+
+Root cause was a PATH version skew. ratio carried two signal-cli installs:
+=~/.local/bin/signal-cli= symlinked to a manual 0.14.5 tree (2026-06-12) and
+=/usr/bin/signal-cli= at 0.14.7 from pacman. The systemd user manager puts
+=~/.local/bin= first, so the timer ran 0.14.5 against a database 0.14.7 had
+already upgraded and signal-cli refused with "Database has been updated by a
+newer signal-cli version". An interactive shell resolved =/usr/bin=, which is
+why it worked by hand and failed under the unit.
+
+Fix: removed the stale =~/.local/bin/signal-cli= symlink, so the pacman-managed
+0.14.7 wins for every caller rather than just the timer. Nothing else referenced
+the 0.14.5 tree. Left the 107M install directory in place — reclaiming it is a
+separate call.
+
+Verified after: the service drained real queued envelopes, including a receipt
+from Craig timestamped 2026-08-16 that had been sitting undelivered, and exited
+=Result=success=. Timer still armed on its 15-minute cadence.
+
+*Correction to this task's original claim.* I first wrote that the pager account
+had not received in 17 days. That number was wrong — the 17-day staleness
+warning belonged to the *personal* account =+15103169357=, proven by draining it
+and watching the warning clear. The pager's failure was real and separately
+established (the database-version error under the unit, plus the 2026-08-16
+envelope still queued), but the 17-day figure was never its. I had attributed
+one account's number to the other because =listAccounts= emits the warning once,
+above the account list, without naming which account it is about.
+
+*Still open, and pre-existing:* nothing keeps the personal account warm.
+=signal-receive.sh= hardcodes the pager account and takes no others, so
+=+15103169357= goes stale until drained by hand — already filed as part of the
+2026-07-23 signal findings, and unchanged by today's fix.
+
+*The durable half is not done and is filed separately below:* the guard in
+=signal-receive.sh= still cannot tell "the account is not here" from
+"listAccounts failed", which is the only reason this ran undetected. Fixing the
+skew without fixing the guard leaves the next failure just as silent.
+
+** TODO [#B] signal-receive guard cannot tell absence from failure :bug:
+:PROPERTIES:
+:LAST_REVIEWED: 2026-08-19
+:END:
+=scripts/signal-receive.sh= guards with:
+
+: if ! signal-cli listAccounts 2>/dev/null | grep -q "$account"; then
+
+The redirect discards any error and =grep= finds nothing either way, so a hard
+failure is indistinguishable from a genuine absence. Both produce the benign
+"not registered on this machine — nothing to do" and a clean exit 0.
+
+That is what let the ratio PATH skew (=[#A]= above) run 17 days undetected while
+reporting success every 15 minutes. The skew is fixed; this is not, so the next
+failure of any kind on that path is equally silent.
+
+Fix: capture =listAccounts= output and its exit code separately. A non-zero exit
+is a failure and should exit non-zero with the error surfaced, never the
+nothing-to-do path. Only a clean run that genuinely lacks the account takes the
+no-op branch.
+
+*Same shape as two other things found today*, which is the argument for treating
+it as a class rather than one script's bug: =triage-intake= reports a clean close
+over a backlog it could not act on (=[#B]= above), and an isolated reviewer's own
+test variant went green because the path under test did not exist and exit 127
+satisfies a =-ne 0= check. A check that cannot distinguish "nothing to do" from
+"could not do it" reports success either way. Worth a sweep for the pattern
+across =scripts/= rather than three separate fixes.
+
+Grading: Major severity (it masks arbitrary failures on a channel whose job is
+reaching Craig when he is away, and masking is worse than failing) x every
+occurrence on that path = P2 = =[#B]=. Not =[#A]= because the live outage it hid
+is now closed.
+
+** TODO [#C] ai-launcher runtime test depends on codex being installed :bug:
+:PROPERTIES:
+:LAST_REVIEWED: 2026-08-19
+:END:
+=scripts/tests/ai-launcher-runtime.bats= test 8 ("--print-runtimes lists claude,
+codex, and one line per ollama model") fails on velox, so =make test= exits 1
+here. Found as the green-baseline run before the agent-text work, and triaged
+rather than fixed so that work could proceed against a known bar.
+
+The test stubs =ollama= but not =codex=, so it asserts on whatever the host
+really has. codex is absent on velox after the 2026-08-13 reinstall, and the
+assertion =[[ "$output" == *"codex"* ]]= fails. The launcher is behaving
+correctly — it lists the runtimes that exist.
+
+This is a test-isolation defect, the same shape as the three ratio-local
+launcher failures filed alongside it: a characterization test that reads the
+host instead of a fixture will pass or fail on where it runs rather than on
+what the code does. Fix by stubbing =codex= on PATH the way =ollama= already
+is, so the test asserts on the launcher's logic.
+
+Two things it is worth not confusing. codex being missing on velox is a real
+reinstall casualty and may be worth reinstalling on its own merits, but that
+would only paper over the test. And the ratio failures are a separate task —
+different tests, different machine, likely different cause.
+
+Grading: Major severity (a red suite makes the green baseline unreadable on the
+affected machine, so every later regression check there is guesswork) x some
+machines sometimes = P3 = =[#C]=.
+
+** TODO [#C] inbox-send cannot reach ~/.emacs.d or ~/.dotfiles :bug:
+:PROPERTIES:
+:LAST_REVIEWED: 2026-08-19
+:END:
+=inbox-send= discovers projects under =~/projects= and =~/code= only
+(=DEFAULT_ROOTS=), so a project sitting directly in =$HOME= is invisible to it.
+=.emacs.d= and =.dotfiles= are both such projects and both carry =.ai/= and
+=inbox/=. So =inbox-send emacsd= fails with "unknown target" even though the
+dot-stripped name resolution it would need is already implemented and working
+(=find_target=, lines 154-175).
+
+Hit for real today: =.emacs.d= sent two handoffs, and I could not reply through
+the normal channel. Worked around with
+=INBOX_SEND_ROOTS="$HOME/projects:$HOME/code:$HOME/.emacs.d"=.
+
+The asymmetry is the defect. =.emacs.d= can send to any project, but no project
+can answer it, which breaks the reply-to-sender discipline in the inbox
+engine's core §4 — and that section's own rationale is that silent
+non-response trains a sender to escalate around the channel. The failure is at
+least loud rather than silent, and an agent that does not know the override
+just drops the reply.
+
+Fix direction: add =$HOME= itself as a scanned root for dotted project
+directories, or add =~/.emacs.d= and =~/.dotfiles= to =DEFAULT_ROOTS=
+explicitly. The docstring already claims "if the root itself is a project, it's
+included", so the intent exists; the roots list is what is short. Note
+=cross-project.md= and =triggers.md= both document =emacsd= as an addressable
+name, so the docs already promise this works.
+
+Grading: Major severity (a protocol obligation is dropped, with a workaround
+only if you know it) x some projects sometimes = P3 = =[#C]=.
+
+** DONE [#B] agent-text relay fallback :bug:
+CLOSED: [2026-08-19 Wed]
+:PROPERTIES:
+:LAST_REVIEWED: 2026-08-19
+:END:
+Approved and applied. =agent-text= hardcoded =VELOX_HOST= as its only ssh relay
+target, and velox's 2026-08-13 reinstall wiped that machine's signal-cli
+registration — so the relay branch pointed at the one machine guaranteed to
+fail, and every machine without a local account relayed into the same dead end.
+
+Took archsetup's proposal over .emacs.d's competing one for the same bug. Both
+replaced the constant with an ordered list; only archsetup's skips a candidate
+whose short name matches =uname -n=, which is the actual defect. .emacs.d's
+works on velox by accident of listing ratio first, so it repairs the instance
+and leaves the defect reachable.
+
+Answered the open question neither sender had tested — a relay host reachable
+but unregistered — by running it on velox, which is that case: =signal-cli
+send= exits 1 with "User +15045173983 is not registered", so the loop advances
+instead of reporting a delivery that never happened. Recorded in protocols.org.
+
+Also corrected =protocols.org= "Reaching Craig", which asserted the same dead
+fact (account "registered on velox (primary) and ratio (linked device)"). Now
+states how to derive it rather than a snapshot, per the host-identity rule —
+the snapshot is what rotted, and a fresh one would rot at the next rebuild. Its
+=signal-mcp= claim was false too: velox's =~/.claude.json= holds only =linear=
+and =slack-deepsat= after the reinstall.
+
+Tests 5 → 10, and the suite now stubs =uname= so the self-skip is
+deterministic rather than dependent on the machine running it. Mutation-proven:
+removing the guard reds 3 tests, an unconditional =break= reds 1, seeding
+=rc=0= reds 1. Decision record:
+[[file:docs/design/2026-08-19-agent-text-relay-fallback-decision.org]].
+
+** TODO [#B] /model writes into the tracked settings.json and blocks the pull :bug:
+:PROPERTIES:
+:LAST_REVIEWED: 2026-08-19
+:END:
+=~/.claude/settings.json= is a symlink into this checkout, and Claude Code
+saves a =/model= or effort change by writing user settings. So every runtime
+model change writes straight into a tracked file, dirties the tree, and blocks
+=git pull --ff-only= at every machine's session start. It blocked this
+session's rulesets pull.
+
+Not a one-off: =git log= on =.claude/settings.json= shows ten prior commits
+flipping the =model= line (=c6bd31f=, =5feaa94=, =e3d3c1c=, =c976f5b=,
+=73835a2=, =d5bc9b3=, =e91073d=, =bd76d98=, =3a5292c=, =ada0e6d=), and
+=effortLevel= has begun doing the same. Treat it as a property of the file, not
+of one key.
+
+Two options, from .emacs.d's handoff (2026-08-14), neither yet chosen:
+1. Stop installing the tracked file as user settings — rulesets holds a
+   canonical template, install copies or merges it, runtime writes land on the
+   machine's own file. Cost: canonical updates stop propagating automatically.
+2. =git update-index --assume-unchanged= per machine. Cheap, but it hides
+   genuine canonical edits too and must be reapplied on every fresh clone,
+   which is exactly the manual step that silently drifts.
+
+Grading: Major severity (recurring startup blocker, no clean workaround) x most
+machines frequently = P2 = =[#B]=.
+
+** TODO [#C] kb-hygiene ships the same report on every run :bug:
+:PROPERTIES:
+:LAST_REVIEWED: 2026-08-19
+:END:
+Ten =kb-hygiene-report.org= files arrived in =inbox/= between 09:15 and 12:56
+on 2026-08-19, all byte-identical (one md5 across all ten). So whatever drives
+=scripts/kb-hygiene.sh= re-ran it ten times in four hours and delivered the
+same output each time. =kb-hygiene.sh= names its report by timestamp
+(=$(date +%Y-%m-%d-%H%M)-kb-hygiene-report.org=), so every run is a new file
+and nothing dedups.
+
+The content was also stale news — 142 agent nodes and ~114 orphans, which the
+=[#C]= KB orphan-node review task already records from 2026-08-04. Deleted all
+ten as script-sourced.
+
+Fix direction: dedup on content before delivering (skip when the new report
+matches the last one), or have the caller deliver on change only. Find the
+caller first — the repeat cadence is the actual bug and it is not in
+=kb-hygiene.sh=.
+
+Grading: Minor severity (inbox noise, wasted processing) x most runs frequently
+= P3 = =[#C]=.
+
+** TODO [#C] Three launcher characterization tests fail on ratio only :bug:
+:PROPERTIES:
+:LAST_REVIEWED: 2026-08-19
+:END:
+.emacs.d reported (2026-08-14) that =scripts/tests/ai-launcher-characterization.bats=
+fails three functional tests on ratio, so =make test= exits 1 there:
+=find_window_id=, =sort_windows=, =attach_mode=. They confirmed the failures
+are pre-existing rather than caused by their two commits, by stashing and
+re-running against a pristine tree.
+
+I re-ran the same suite on velox today: 36 tests, all green, including exactly
+those three. So this is environment-dependent and ratio-local, not a code
+defect that reproduces fleet-wide. All three are the tmux-driven functional
+tests, which points at ratio's tmux state or version rather than the launcher.
+
+Diagnose on ratio (reachable over tailscale). It matters more than the [#C]
+suggests in one respect: a red suite on ratio poisons the green-baseline
+discipline, so every later "did I break this?" check there is unreadable until
+it is fixed.
+
+Grading: Major severity (unreadable baseline on the affected machine) x rare
+edge case (one machine, and velox is clean) = P3 = =[#C]=.
+
 ** TODO [#B] Voice pattern #48 — corrective antithesis :feature:
 :PROPERTIES:
 :LAST_REVIEWED: 2026-07-31