A hook is a small piece of automation attached to an event in a workflow. In our coding environment, those hooks became the work: terminals kept demanding attention, execution became blocked, and the repair process ran into the same infrastructure it was trying to fix.

The immediate frustration was obvious. The architectural problem took more care to describe. If ordinary agent work and recovery both depend on a failing execution path, asking the agent to try again may just produce another blocked attempt.

As of the September 28 work session, the targeted repair remained incomplete. That unfinished state is part of the lesson.

One visible terminal is only part of the answer

My initial direction was to group execution behind one supervisor terminal. I wanted one place to understand what was happening instead of a cascade of windows.

That is a useful interface goal, but it leaves operational questions. Who started each process? Which request does it belong to? Is another copy already running? What happens when a request times out? What is allowed to restart it?

A supervisor needs answers to those questions before a single terminal can provide a trustworthy view. Otherwise the clutter may disappear while the underlying duplicate work continues.

Retries need an end condition

The repair effort focused on bounded retries, circuit breaking, duplicate-request coalescing, structured backpressure, emergency-stop receipts, and termination of owned child processes.

In ordinary language: stop retrying after a defined limit, pause a repeatedly failing path, avoid starting the same work twice, explain when the system cannot accept more work, and record what an emergency stop actually did.

Process ownership matters especially when stopping work. The intended target is the child process associated with the operation. Other work in the environment needs to remain identifiable and separate.

These mechanisms have to fit together. A timeout is not sufficient if a second component immediately submits the same request again. A stop button is not sufficient if a background retry brings the work back.

A passing test run was not a completed repair

The initial targeted run reported 23 passing tests. Those covered bounded retries, the incident's stop-loop sequence, duplicate-request coalescing, and stopping an owned child without harming an unrelated process. Typechecking passed; lint reported failures.

Later hardening edits remained untested. The live harness then blocked the next edit with HOOK_INFRASTRUCTURE_BLOCKED. The repair could not be called complete on the strength of the earlier test run.

That distinction changes the handoff. Another agent needs to know which version was tested, what changed afterward, and where execution stopped. A single green status would conceal the information needed to continue safely and efficiently.

Recovery must be a designed workflow

The next repair package needs to target the blocked path specifically. Our proposed sequence is to record the failure, perform an authorized repair, replay the affected operation, and promote the result only after verification.

That is a design requirement, not evidence that automatic recovery is already operating. Recovery must retain the system's authority boundaries and make its own actions inspectable.

For me, the practical acceptance test is straightforward: reproduce the failure, show that retries stop, demonstrate recovery through its intended controls, and complete the originally blocked task. Until that sequence works, the incident stays open.

Record and method

Written September 28, 2026, from the hook-repair work session and its reported test and blocking results. AI assisted with drafting. The counts describe the initial targeted run, not a fresh audit or a verified end-to-end recovery. For the earlier control-design discussion, read Stop the command. Keep the terminal..