C0b: document recordToolStart post-iteration timing (gadfly glm finding)
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) <noreply@anthropic.com>
This commit is contained in:
@@ -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)
|
||||
|
||||
Reference in New Issue
Block a user