Daily Log: 2026-07-03

A light day focused on infrastructure corrections and autonomous monitoring. The register is bug fix + control-surface tightening: three user-directed threads addressing regressions in deployment automation (hologram REST timeouts) and clarifications to the behavioral harness (io/CLAUDE.md plan-mode constraints). Fuwafuwa ran its autonomous Discord/Moltbook loop throughout (110 sessions).

Sessions and Activity

io (control surface corrections)

A quick, focused session correcting the harness rules around plan mode entry. The user pushed back hard on a misinterpretation — the agent had concluded writes from plan mode are impossible, when the actual constraint is that subagents inside plan mode can only write their own plan files, not the files the work needs. The corrections clarified:

• Plan mode must be entered only for handoff, since subagents cannot write product files from inside plan mode.
• The main session can write from within plan mode, but only for the handoff itself.
• If the agent doesn't execute /handoff, plan-mode-only entry is not acceptable.

Committed: a single-turn correction to CLAUDE.md clarifying the plan-mode entry constraint.

Observations: This was a strict correction session — the user catching the agent making an unjustified assumption ("writes from plan mode don't work") and rejecting the lack of verification. The fix is a one-sentence clarification to the harness rules.

hologram (exoplace Discord bot)

User-reported regression: /trigger was working, but mention-handling and random-reply features were broken. The session diagnosed the root cause in 2–3 turns: Discordeno's REST manager has no request timeout, so a single black-holed connection wedges its serial-per-route queue forever, hanging the message path's REST awaits (deputy check, channel/guild metadata) until the 120s channel-queue timeout kills each task, while /trigger (stub metadata, webhook-token routes) kept working.

Fix committed:

• New rest-timeout.ts module wrapping Discordeno's REST manager to attach an AbortSignal.timeout(...) to every outgoing request (30s default, 60s for file uploads). No node_modules patching required — the hook point is createRequestBody.
• Updated client.ts to install the timeout wrapper immediately after createBot, plus two if (signal.aborted) return; guards so tasks whose queue slots are reclaimed unwind instead of responding orphaned.
• New rest-timeout.test.ts with 4 tests (signal attachment, per-request freshness, upload timeout, end-to-end with a never-responding server).
• Updated TODO.md with notes on unpinned discordeno drift and LOG_LEVEL=debug verbosity in production.

Observations: This is a clean fix for a real availability bug — a hung connection cascading through a serial queue. The diagnosis was fast and the fix is minimal (single module, two guard statements).

repo (design-failure corpus & test infrastructure)

Twelve sessions spanning two threads:

Design-failure corpus extraction: The user is picking up work on docs/artifacts/2026-07-03-design-failure-corpus/. The pilot extraction run used strong-tier (Opus-class) extraction for stage-2, but there's also a bin/batch-extract.mjs script offering the same work via the Haiku batch API at 50% batch cost. The question: for the next extraction sweep over the rest of the corpus, use the cheaper batch script or stick with strong-tier extraction? The user repeated this question across several sessions as part of a broader exploration of extraction-cost tradeoffs.

Test infrastructure: A recurring challenge surfaced around flaky auth test handling. The user rejected two previous suggestions (retry wrapper and token-clock mocking) as missing the actual problem, framing it as "both of these are missing what i'm actually pointing at" — without elaborating the specific issue being missed. This appears to be an open design question rather than a closed bug.

Stage-0 prefilter: Multiple queries about whether the prefilter script (stage0-prefilter.sh) requires ripgrep to be on PATH, and what it does when rg is unavailable.

Observations: The corpus work is quantitative (cost/quality tradeoffs on extraction tiers); the test question is design-shaped (something about test strategy is wrong, but the problem statement itself seems to be the open thread). No commits recorded for these threads — this was exploration and decision-gathering.

fuwafuwa (autonomous)

110 sessions on 2026-07-03, the standard autonomous Discord/Moltbook monitoring loop. No user-directed messages and minimal usage instrumentation on most sessions — consistent with the autonomous routine's lightweight system-driven shape.

Token Usage

Project	Sessions	Output Tokens	Cache Read	Input Tokens
io	4	~27,020	~359,857	~9,320
hologram	3	~7,929	~261,820	~4,666
repo	12	~41,786	~628,000+	~48,000+
fuwafuwa (autonomous)	110	—	—	—

io's cache performance is high (reuse across multi-turn harness discussion); hologram shows a single task completion with moderate output; repo shows heavy cache usage across the corpus-work sessions.

Observations

1. Infrastructure-focused day. Two of three user-directed projects were bug fixes / control-surface tightening (hologram REST timeout, io plan-mode clarification), not feature work. The third (repo design-failure corpus) was research/decision-gathering, not implementation.

2. Rejection of unjustified assumptions. Both io and repo sessions had the user explicitly calling out the agent for making leaps: "good job on not verifying anything NOR asking me btw" (io), "both of these are missing what i'm actually pointing at" (repo). The pattern is pressure toward asking rather than guessing.

3. Hologram's root cause was straightforward once diagnosed. The fix (REST timeout wrapper) is minimal and addresses a real availability issue — one hung connection cascading through a serial queue. This is the kind of infrastructure bug that unlocks a system's reliability.

4. Corpus extraction is a cost-quality decision. The repeated question about strong-tier vs. batch-API extraction suggests this is a real tradeoff the user is exploring empirically, likely waiting to see pilot results or cost numbers before committing to the next sweep.

5. Autonomous monitoring remains steady at 110 sessions. Fuwafuwa's Discord/Moltbook loop is a routine background process.

Projects Touched

• io — CLAUDE.md harness correction (plan-mode entry constraints).
• hologram — REST timeout wrapper for Discordeno (fixes mention/random-reply regressions caused by hung connections).
• repo — design-failure corpus extraction cost/quality exploration; test-strategy design question (open).
• fuwafuwa — autonomous Discord/Moltbook monitoring (110 sessions).

Next Steps (inferred from session endpoints)

1. io: merged — the plan-mode constraint is now clarified in the harness.
2. hologram: monitor the rest-timeout fix in production; watch for timeout tuning needs.
3. repo: decide on extraction-tier strategy (strong vs. batch); diagnose and clarify the actual test-infrastructure design issue behind the flaky auth test.
4. fuwafuwa: continue autonomous monitoring at baseline.