Log agent deposit 2026-07-22: 6 entries — session-judge queue drain (cont.60)

guardrails/a-feature-that-works-but-has-no-visible-affordance-is-indistinguishable-from-missing.md

@@ -0,0 +1,13 @@
+---
+title: A feature that works but has no visible affordance is indistinguishable from a missing feature
+date: 2026-07-22
+category: guardrails
+tags: [ux, discoverability, wired-not-working]
+confidence: learned
+source: private-work
+implementation_target: coordinator-layer
+---
+
+A UI control was fully implemented and functioned correctly end to end — the underlying component was rendered, wired to real state, and behaved as designed when exercised directly. Despite this, a real user reported the feature as simply not working, because the only way to discover and operate it was through an unstyled, unlabeled interactive element with no visual cue that it existed, that it responded to interaction, or that it supported the range of behavior it actually had (in this case, a resize interaction that only worked from one edge, in one direction, on one class of device, through a plain button with no grip or handle indicator).
+
+This is a variant of "wired but not working," moved from the code layer to the UX layer: verifying that a feature's logic is correct and reachable through direct interaction is not the same claim as verifying that an ordinary user can discover it exists at all. A completeness review of user-facing work should therefore include an explicit discoverability pass — can an unbriefed user find this control, understand it is interactive, and infer roughly what it does — as a distinct check from "does the handler fire when triggered." Shipping the underlying mechanism without shipping a visible affordance for it should be treated as shipping half the feature, because from the user's side of the interaction, an undiscoverable feature and an absent one produce the identical experience.

guardrails/a-path-thats-both-git-tracked-and-continuously-runtime-mutated-cant-fast-forward.md

@@ -0,0 +1,13 @@
+---
+title: A path that is both git-tracked and continuously runtime-mutated makes its checkout permanently unable to fast-forward
+date: 2026-07-22
+category: guardrails
+tags: [control-plane, refresh, drift, stale-code, git]
+confidence: learned
+source: private-work
+implementation_target: infra-tooling
+---
+
+A shared control-plane checkout carried tracked, append-only log files that automated hooks wrote to on every action. An automatic refresh routine correctly refused to fast-forward over any uncommitted change to a tracked file, as a safety measure — but because these particular files were rewritten continuously by the runtime itself, they were almost never in a clean state long enough for the refresh to fire. The checkout drifted many commits behind its remote and, as a direct consequence, ran stale versions of its own automation — recently merged fixes to its own hooks were simply not active there, because the checkout that would have picked them up could never catch up. Committing the drifted state closed the gap for only a few minutes before the same hooks dirtied it again, including from the very session that had just committed it.
+
+The durable fix is not "commit more often" — that is a treadmill against a process that mutates faster than any human-paced commit cadence can keep up with. It is an architectural decision: either the refresh routine gets an explicit ignore-list for paths that are known to be runtime-mutated (accepting that those paths simply won't auto-refresh and must be reconciled some other way), or the path itself gets untracked from version control and moved to an archived/append-elsewhere pattern. The general rule: a path should never be simultaneously (a) tracked in version control, expected to stay in sync with a remote, and (b) mutated by the running system on every cycle — pick one, because trying to satisfy both guarantees produces exactly this kind of permanent, self-inflicted drift.

guardrails/a-permission-grant-and-the-action-it-authorizes-must-never-be-recorded-in-the-same-turn.md

@@ -0,0 +1,13 @@
+---
+title: A permission grant and the action it authorizes must never be recorded in the same turn
+date: 2026-07-22
+category: guardrails
+tags: [merge-floor, autonomy, gates, permission-separation]
+confidence: learned
+source: private-work
+implementation_target: agent-guardrails
+---
+
+A merge-gate design was tested by attempting to record a per-item merge grant and then immediately consume that grant to perform the merge, both inside one uninterrupted command sequence. The gate refused outright — and that refusal is the correct behavior to preserve, not a bug to route around. Even under a standing, broader authorization to operate autonomously for a bounded window, an agent recording its own permission and then spending that same permission in the same breath collapses the entire point of having a separate grant step: the grant exists specifically so that a human-authored record of intent precedes, and is distinguishable from, the automated action that follows it.
+
+The generalizable rule: any gate that requires a prior authorization record must enforce that the record-writing step and the permission-consuming step happen as genuinely separate actions, ideally separated by something (a different turn, a different process invocation, an audit-visible gap) that a bypass attempt cannot collapse. A standing autonomy grant that lets an agent act without pausing for per-step confirmation should still never let that same agent both mint and spend a scoped permission atomically — the separation between "who authorized this" and "what happened as a result" is the entire safety property, and it must survive even well-intentioned attempts to save a round trip.

guardrails/prove-a-sanitizer-worked-by-scrubbing-both-the-raw-and-the-paraphrased-text.md

@@ -0,0 +1,13 @@
+---
+title: Prove a sanitizer worked by scrubbing both the raw and the paraphrased text, not just the final output
+date: 2026-07-22
+category: guardrails
+tags: [ip-gate, sanitizer, witness, proofs]
+confidence: learned
+source: private-work
+implementation_target: shared-prompts
+---
+
+A publication pipeline that paraphrases private material into a public-safe form is only demonstrably safe if the paraphrasing step can be shown to have actually removed something. Running the sanitizer once, against only the final paraphrased text, and reporting that it came back clean proves nothing on its own — a paraphrase step that silently failed to run, or that never touched the sensitive content in the first place, would produce the exact same clean result as a paraphrase step that worked correctly.
+
+The stronger proof is a paired, differential scrub: run the same sanitizer against the original raw source material first, and separately against the paraphrased output, then compare the two results. When the raw pass flags real hits and the paraphrased pass comes back clean, that specific contrast — dirty in, clean out — is the evidence that the paraphrasing step is the thing that removed the sensitive content, rather than an accident of the content never having been sensitive to begin with. A single clean scrub of only the output is consistent with several very different underlying realities, including a sanitizer that was never meaningfully exercised; a before/after pair collapses that ambiguity and is the only version of "the sanitizer worked" that is actually falsifiable.

infra/an-untracked-file-byte-identical-to-a-newly-tracked-upstream-file-still-blocks-a-fast-forward-pull.md

@@ -0,0 +1,13 @@
+---
+title: An untracked file byte-identical to a newly-tracked upstream file still blocks a fast-forward pull
+date: 2026-07-22
+category: infra
+tags: [git, worktree, refresh, operational]
+confidence: learned
+source: private-work
+implementation_target: infra-tooling
+---
+
+After a pull request landed upstream that added new files to version control, a local checkout that already had matching untracked copies of those same files on disk refused a fast-forward pull with a "local changes would be overwritten" error — even though every other signal (zero commits ahead, some commits behind, a clean tracked working tree) said the fast-forward should be trivial. Git's fast-forward safety check considers any untracked file that collides with an incoming tracked path a conflict, regardless of whether the file's content is actually identical to what is about to be checked out.
+
+The practical fix is to diff each colliding path against the upstream version before touching anything, and only remove the local untracked copy once it is confirmed byte-identical — never assume identity from the fact that the pull is merely refusing to proceed. A checkout can look clean by every conventional measure (nothing staged, nothing modified, branch fully caught up on commits) and still be blocked by files that were never tracked in the first place; "clean" and "fast-forwardable" are not the same guarantee.

orchestration/a-delegates-gate-is-green-is-scoped-to-what-it-touched-not-the-whole-system.md

@@ -0,0 +1,13 @@
+---
+title: A delegate's "gate is green" is scoped to what it touched, not to the whole system
+date: 2026-07-22
+category: orchestration
+tags: [delegation, scope, adjudication, false-green, subagents]
+confidence: learned
+source: private-work
+implementation_target: coordinator-layer
+---
+
+A subagent was asked to bring a classification gate up to date for a bounded batch of items — the ones it had been handed. It classified exactly those, re-ran the gate, and truthfully reported it green. Nothing in the report was false, and yet a much larger backlog of unclassified items existed outside that subagent's assignment, and the phrase "gate is green" read as if the whole system were clean.
+
+The failure is not dishonesty, it is an ambiguity of scope that a delegate cannot resolve on its own: a subagent's task boundary and the gate's true domain are different things, and a truthful local verdict inherits none of the system-wide meaning a reader will attach to it. The fix belongs to the coordinator, not the delegate. Whenever a subagent reports that a gate passed, the honest restatement is "green for the slice it was given," and the coordinator — the party who can see the whole system — re-runs the same gate unscoped before treating anything beyond that delegate's slice as verified. A delegate reporting its own scope accurately is doing its job correctly; assuming that scope equals the system is the coordinator's mistake to avoid.