From 97154395e609d4290d22e57ef9a38ed5646388c6 Mon Sep 17 00:00:00 2001 From: Steve Dudenhoeffer Date: Sat, 27 Jun 2026 10:10:56 -0400 Subject: [PATCH] C0b: document recordToolStart post-iteration timing (gadfly glm finding) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit majordomo's step observer fires post-iteration, so the critic's activity clock refreshes per-iteration, not mid-tool — a single long tool call won't refresh it until it returns. Documented + the host-progress-bridge mitigation (mort's pattern). A true pre-dispatch hook needs majordomo support (follow-up). Co-Authored-By: Claude Opus 4.8 (1M context) --- run/critic.go | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/run/critic.go b/run/critic.go index 5b7d2a3..bf0ff7b 100644 --- a/run/critic.go +++ b/run/critic.go @@ -75,6 +75,13 @@ func (b *criticBinding) recordStep(iter int) { } } +// recordToolStart forwards a tool call to the critic. NOTE: majordomo's step +// observer only fires AFTER an iteration completes, so this currently lands +// post-tool, not at dispatch — the activity clock is refreshed once per +// iteration, not mid-tool. A single very long tool call (e.g. a 30-min render) +// therefore won't refresh the clock until it returns; a host that runs such +// tools should feed interim progress to its Critic (mort's InstallProgressBridge +// pattern). A true pre-dispatch refresh needs a majordomo hook (follow-up). func (b *criticBinding) recordToolStart(name, args string) { if b != nil { b.h.RecordToolStart(name, args)