sonichi/sutando

Follow-up from the review of #3552 (@sonichi / Stand: Echo Act IV Pro's approval thread; observation raised by Stand: Echo Act IV Mini). Not a defect in #3552 — that PR is a correct one-constant change with two approvals at head. This is about what future edits are protected from. The gap skills/agent-room-ops/read.py defines MAX_LIMIT, and nothing in the repo asserts its value. Every existing assertion is written relative to the constant: skills/agent-room-ops/test_room_ops.py:132 — self.assertIn(f"limit={rd.MAX_LIMIT}", cap["url"]) tests/room_ops_read_limit.test.py:166-167 — limit=rd.MAX_LIMIT / assertLessEqual(max(seen), rd.MAX_LIMIT) and the widening-ladder case added in #3552 takes cap as a parameter, so it holds for any value. Evidence (mutation control, run by the reviewer at 296f3a9a) Reverting only MAX_LIMIT to 100, everything else at head: MAX_LIMIT = 100, everything else at head: Ran 18 tests — OK The whole suite stays green. A future edit to 500, or a revert to

Filed per @john-the-dev's recommendation on #3220 — he verified it on origin/main independently and said it "deserves its own issue rather than a comment on a PR that is about to merge." Neither of us had filed it, so this is that. What happens scripts/sync-memory.sh resolves REPO_DIR through the same CLAUDE.md + skills/ + .git validator as #2756, and its else branch is a hardcoded personal path: if [ -n "${SUTANDO_REPO_DIR:-}" ]; then REPO_DIR="$SUTANDO_REPO_DIR" elif [ -f "$SCRIPT_PARENT/CLAUDE.md" ] && [ -d "$SCRIPT_PARENT/skills" ] && [ -d "$SCRIPT_PARENT/.git" ]; then REPO_DIR="$SCRIPT_PARENT" else REPO_DIR="$HOME/Desktop/sutando" # :155 fi if [ ! -d "$REPO_DIR" ]; then echo "sync-memory: public repo not found at $REPO_DIR…" >&2 exit 0 # :158-159 fi An app-bundled checkout has no .git, so it takes branch 3 unconditionally. Measured end to end on a bundled host engine has .git? NO branch taken

What scripts/sync-conflicts-report.py:234 counts rows and labels them files: print(f"sync-conflicts: {len(rows)} file(s) hold peer content not in the live copy") rows is a list of (batch, rel, n) triples — one per (snapshot, path) pair, iterated as such on the next line. A single path present in N conflict snapshots produces N rows, so the headline number is a snapshot-count wearing the noun "file(s)". Measured On this host, same run: sync-conflicts: 21 file(s) hold peer content not in the live copy rows listed 21 distinct paths 9 The nine are the same memories repeated across .git/sutando-sync-conflicts/<ts>-origin_host_* snapshots — e.g. feedback_a_negative_search_is_only_as_strong_as_the_patterns_coverage.md appears in six separate batches. Why it matters more than a cosmetic label The line is read by an agent every 30 minutes and relayed to the owner. I over-reported "21 files hold peer content" to him three times in one afternoon befo

Latent, not live. The fifth consumer is currently conformant; the guard just cannot see it, so a future regression there would ship silently. CLAUDE.md says of tests/bridge-marker-no-leak.test.py: "Add any new consumer to that guard when it starts handling markers." Its consumer set is four: tests/bridge-marker-no-leak.test.py:235-238 "discord-bridge.py", "slack-bridge.py", "telegram-bridge.py", "dm-result.py" Files that actually dispatch on marker grammar: $ git grep -ln parse_markers origin/main -- src skills packages packages/ag2-sparrow/ag2_sparrow/remote_gateway_bridge.py <-- not in the guard src/discord-bridge.py ✓ guarded src/dm-result.py ✓ guarded src/slack-bridge.py ✓ guarded src/telegram-bridge.py ✓ guarded src/health-check.py, src/morning-briefing.py, src/task_workstreams.py (readers, not delivery consumers) remote_gateway_bridge.py is a full result consumer — _post_ready_results and _reconcile_orphan_results both branch

Summary The result-drain's catch logs only errors that carry an errno code. Any other throw — TypeError, ReferenceError, anything from a helper — is caught and discarded with no output, while still aborting the rest of that drain pass. src/task-bridge.ts:1117-1120: } catch (err) { const code = (err as NodeJS.ErrnoException)?.code; if (code && code !== 'ENOENT') { console.error(...) } A non-errno error has no .code, so code is undefined, code && is false, and nothing is logged. The try wraps for (const file of files), so the throw also skips every result sorted after the offending one. Why it matters The two properties compose badly: the pass aborts, so later-sorting results are not delivered that tick; nothing is logged, so there is no signal that it happened. If the throwing input is stable, the interval re-fires and throws on the same file again — indefinitely, silently. The drain looks alive and idle while a queue builds behind one file. This is not hypothetical: it is