agent-attach.test.sh [9]: the sweep is SANDBOXED (finding refuted at HEAD) but its runtime is unbudgeted - measure before touching it
SUITE OWNERSHIP: agent-attach.test.sh came in under 093b5a2 and carries no Owner line; bin-whey-cc handed it to me 2026-09-18 and coder03-mba-l-cc closed their side per Elazar (agent-attach.sh v2.7.1 = 9343ff4 stands, converged all three hosts). This row is the suite, not the script. FINDING 1 IS REFUTED AT HEAD, AND THE REFUTATION IS THE POINT. Relayed claim (bin-whey-cc, sourced from coder03-mba-l-cc on lezama): 'test [9] calls $AA "$n" with no tty, so any RESOLVABLE name reaches the real harness and attaches - basquetwi-pm cost 40.7s of a 61s loop; whether $TMP/bin is sandboxed has not been verified.' It IS sandboxed, and I verified it rather than reasoning about it. agent-attach.test.sh:37-39 writes echo-only cc-tmux.sh and ca-tmux.sh stubs into $TMP/bin beside the copied SUT. agent-attach.sh:565-574 execs "$SCRIPT_DIR/$harness_sh" - an ABSOLUTE path off SCRIPT_DIR, never a bare PATH name (deliberate, v1.4: an ssh command-exec shell has no ~/.local/bin on PATH) - and SCRIPT_DIR is derived at :157 from readlink -f of BASH_SOURCE. :36 is a plain cp, so SCRIPT_DIR resolves to $TMP/bin and the stub answers. There is no third harness value (:537-538, :552-553) and a missing stub exits 5 rather than falling back. Measured on venus in the suite's own fixture shape: $AA bin-venus-cc -> 'HARNESS=cc AGENT=bin-venus-cc' in 0.387s. No tmux session was touched. WHAT THE REPORTERS ACTUALLY OBSERVED was the REAL ~/.local/bin/agent-attach.sh run by hand - whey's reproduction is quoted as 'agent-attach.sh bin-whey-cc', not $AA, and coder03's non-reproducing 0.49s re-run is a manual invocation too. Same script, different SCRIPT_DIR, opposite blast radius. THE DEFECT CLASS: a sandbox that works by PATH-of-the-copy is invisible at the call site - "$AA" "$n" reads identically to a live attach, so a hand re-run to investigate silently leaves the sandbox and confirms a side effect the test never had. Do not fix this by making the test avoid resolvable names; that would remove the only coverage of the resolve->exec path. CAVEAT, and it is why this is filed rather than closed: I measured HEAD on venus. coder03 ran lezama's DIRTY copy, which carries 19 unpushed insertions including an extra '[7] adjacent-transposition' test that shifts every later number (so their '[1]-[9] PASS' maps to HEAD's [1]-[8]). I cannot rule out that the dirty copy invokes the harness differently. Those 19 insertions are still uncommitted and unowned in lezama's checkout - decide keep-or-discard before anyone measures that host again. FINDING 2 ACCEPTED AS WITHDRAWN: the prune rewrite of the line-297 find is NOT behaviour-preserving. whey's 0.35s->0.16s compared two different queries (75 vs 81 files); lezama's pair returns 23 vs 60. The -not -path exclusions are load-bearing for the assertion per the suite's own comments (trash, gdrive backup snapshots, .cache, _quarantine, .claude are deliberately not-live declarations). Do not re-propose it. WHAT IS STILL REAL: [9]'s runtime is unbudgeted and nobody has a venus number. The full suite exceeded 600s here without completing. Measuring the find and the per-name loop SEPARATELY is the open work - the two reporters' figures disagree (540s+ cold vs 7.9s cold / 0.57s warm for the find alone on lezama) and neither separated them. Attach the venus split to this row before proposing any change.
Activity
-
AMENDMENT - the 'do not re-propose the prune' clause above is WRONG and is superseded here. Leaving it uncorrected would be the exact failure OPS-265 was written about: a stale we-measured-this-and-it-fails that the next reader trusts and stops at. WHAT THE WITHDRAWAL ACTUALLY SHOWED. bin-whey-cc withdrew the prune rewrite because the two forms returned different file counts (whey 75 vs 81, lezama 23 vs 60). That is evidence their prune arms were MIS-TRANSLATED, not that pruning cannot preserve the set. Every exclusion in the line-297 find has the shape -not -path "<dir>/*", which is precisely what -prune expresses. The two ways to get a different count are dropping the trailing /* (the pattern then no longer names the directory) and omitting -print (find's implicit print fires on the pruned nodes too). Both counts are consistent with one of those. MEASURED ON VENUS 2026-09-18, and the gap is not marginal: - prune form (patterns without the trailing /*, explicit -print): 0.701s, 91 files. - as-written form: EXCEEDED 15 MINUTES WITHOUT COMPLETING, twice. First run killed at ~15min mid-traversal (/proc cwd confirmed it was still walking), second still running at the time of this note. MECHANISM, which is why the gap is three orders of magnitude rather than a constant factor: -not -path is a POST-FILTER, not a prune. find DESCENDS INTO every directory the list is meant to exclude and discards the results afterwards - so it walks every node_modules and every .git object tree under $HOME before throwing them away. -prune stops the descent. lezama's 7.9s cold and whey's 0.35s are hosts with few worktrees; venus is not, and the same expression that is merely slow there is UNRUNNABLE here. SO THE STATUS OF [9] IS WORSE THAN 'unbudgeted': the test cannot complete on venus at all. The full suite exceeding 600s is this one line. STILL OPEN, and it is the thing that decides it: COUNT EQUALITY IS NOT SET EQUALITY. The as-written list must be captured and diffed against the prune list path-by-path, not compared by number - a matching count over different sets is exactly the trap that produced the withdrawn 75-vs-81 comparison in the first place. That diff is pending on the as-written run finishing. Until it lands, the correctly-translated prune is UNTESTED FOR EQUIVALENCE, not proven equivalent - and it is certainly not refuted. The load-bearing point from the withdrawal SURVIVES and must be carried into any rewrite: the -not -path exclusions are part of the assertion, not housekeeping (trash, gdrive backup snapshots, .cache, _quarantine, .claude are deliberately not-live declarations, per the suite's own comments at :290-296). A prune translation has to preserve that set exactly, which is what the diff checks.
-
WHEY CONFIRMS THE TRANSLATION, AND ITS OWN RESULT DOES NOT DECIDE VENUS. bin-whey-cc re-ran the prune with all 11 exclusions (their first attempt dropped 7 of them, which is the whole of the 75-vs-81 mismatch that produced the withdrawal). Faithful form: find "$HOME" -maxdepth 9 \( -path "*/.claude/agents" -o -name node_modules -o -name .git -o -path "$HOME/.local/share/Trash" -o -path "$HOME/gdrive" -o -path "$HOME/.Trash*" -o -name backup -o -name backups -o -path "$HOME/.cache" -o -name "_quarantine*" -o -path "$HOME/.claude" \) -prune -o -name .agent-name -type f -print Their translation notes are correct and worth keeping: -not -path "*/backup/*" matches a dir named backup at ANY depth, so it becomes -name backup and NOT a rooted -path; "*/.claude/agents/*" is nested so it stays a rooted -path while $HOME/.claude is its own term; -name .git also matches the linked-worktree marker FILE, which -prune treats as a no-op and which can never match -name .agent-name anyway. WHEY RESULT: 75 and 75, lists sorted and diffed PATH-BY-PATH, diff empty. Timing 0.531s as-written vs 0.485s pruned - no meaningful delta, which is the predicted shape rather than a counter-example: whey has 2 linked worktrees, so there is nearly nothing to stop descending into. The prune's value is entirely on hosts with deep excluded trees. WHAT THIS DOES AND DOES NOT ESTABLISH. It establishes that the EXPRESSION is a faithful translation of the exclusion set. It does NOT establish equivalence over venus's corpus, because whey contains none of the pathological trees - and the whole reason this is open is that the two hosts differ precisely there. Same trap as the count comparison, one level up: a clean diff on the host where nothing is excluded is not evidence about the host where everything is. VENUS STATUS, unchanged: the as-written find has now exceeded 25 minutes without completing, on its second attempt (the first was killed at ~15min mid-traversal, /proc cwd confirmed it was still walking). Until it yields a list there is nothing to diff, and the prune stays UNAPPLIED. Venus prune form alone: 0.701s, 91 files. NOTE THE ASYMMETRY that makes this awkward to close: the measurement needed to authorise the fix is the very operation the fix exists to make possible. If the as-written find never completes on venus, a path-by-path diff on this host is UNOBTAINABLE, and the decision has to be made on the translation's correctness plus whey's and lezama's diffs instead - which must then be stated as such, not dressed up as a venus verification. Do not let a timeout become a silent pass.
-
CLOSED 2026-09-18. agent-attach.test.sh v1.7 pushed; the suite completes on venus for the first time - 14 passed, 0 failed, 0 skipped, 84s. RESOLVED, in order: 1. The relayed 'sweep launches real harnesses' finding: REFUTED at HEAD and withdrawn by bin-whey-cc after they re-verified it themselves. Both reproductions were by-hand runs of the real script. Durable lesson saved to memory: a fixture that sandboxes by PATH-OF-THE-COPY reads identically at the call site, so investigating by hand silently leaves the sandbox and confirms a side effect the test never had. 2. The prune: APPLIED. The 'do not re-propose it' clause I wrote into this row was wrong and is superseded by the amendment above - that was the OPS-265 stale-comment failure landing on my own ticket, caught by review rather than by me. 3. Equivalence: established WITHOUT the 40-minute walk, which is the part worth keeping. bin-whey-cc's decomposition: direction A (prune-set minus as-written-set) is pure string predicates over a list already in hand - no filesystem access - and came back 91/91 clean on venus, 75/75 on whey. Direction B is textual by construction, since -prune's only effect is to stop descent, so anything it drops has a pruned ancestor and therefore satisfies the 'X/*' exclusion that ancestor's pattern came from; the two can only diverge there through a mistranslated PATTERN PAIR. Two independently written translations produce identical 91-path sets on venus. THE MEASUREMENT THAT LOOKED REQUIRED WAS NEEDED ONLY FOR THE DIRECTION THAT TURNS OUT NOT TO NEED IT - worth remembering next time a ticket looks blocked on an operation the fix exists to make possible. 4. Runtime: 0.312s vs >40min unfinished. The '~80s on venus' note in the file was accurate all along; the find was the broken part, not the per-name loop. I had edited that note and put it back. FOUND BY THE FIX, and this is the return on it: [9] went red on its first completing run, on scrp-journal-digest-venus. Corpus defect, not a resolver gap - a scrp-* name is a script sender with no session, so a resolver reaching it would be the bug. Now counted in its own bucket and named on BOTH the pass and the fail line. ONE THING NOT FIXED AND NOT MINE: /home/rob/.local/state/journal-digest/.agent-name writes 'cc=scrp-journal-digest-venus' - the harness KEY says cc while the NAME says script, and agent-conventions.md reserves cc/ca for reasoning agents precisely so the two cannot be confused. It is harmless to the resolver (nothing attaches to it) and the declaration is load-bearing for KPI attribution, so it must NOT simply be deleted. Routed as a question to the scrp- grammar's owner rather than changed here. NOT EXERCISED: lezama has not run v1.7. The as-written baseline find never completed on venus, so there is no disk-truth diff from this host - equivalence rests on direction A plus the textual argument, and that is stated rather than dressed up as a venus verification.