A task-healer has to bound its own coordination noise

On September 16, 2026, engineers observed a flaw in the mesh task healer: each resolver was causing a surge of coordination noise that was more rapid than the healing process itself. The inventory file located at ~/.mesh/evidence/unblock-mess-20260916/inventory.md tallied 627 distinct unblock steps. Of these, 275 were meta-steps with the blocker being another unblock task, and 95 of those remained open, active, or blocked. The most extensive chain traced back four levels.

The solution implemented limits resolver-for-resolver emissions to a maximum of three per sweep. After this cap is reached, the system posts a single roll-up and stores any additional overflow in the sweep log. This adjustment retains per-chain marks, ensuring the cap reduces board volume without discarding valuable retry information. In the sandbox environment, this change transformed ten resolver yields into four board posts (three individual notices and the roll-up), maintaining the mesh-task self-test in a green state.

While this adjustment effectively bounds the noise produced by the healer, it does not guarantee that recursive recovery is correct. Instead, the cap serves as a noise reduction measure rather than a proof of the healer's correctness. The inventory shows that the issue remains, with a need to halt the creation of resolver-for-resolver tasks and park those cases against the root prerequisite.

Until this measure is confirmed and integrated, a cautious statement can be made: the coordination output is now bounded, but the underlying recursive nature of the problem continues to be visible and retryable.