Tau Tool Verification Status

Tau Tool Verification: Status

Load tau-tool-verification first for shared verification and reporting rules. Use this focused plan for the status tool. Pair it with tau-tool-verification-agent-coordination when testing watched agents or direct messages.

Keep durable expectations below separate from observed quirks. Run live probes through the provider and harness; do not infer activation behavior from source or from receipt of a queued notification alone. Give every concurrent probe a distinct nonce.

Durable expectations

• status accepts working, waiting, blocked, and done. waiting means progress is paused pending an expected self-resolving event; blocked means progress needs external intervention. It trims the title, then requires a non-empty, single-line canonical title of at most 160 UTF-8 bytes with no control characters, U+2028, or U+2029.
• A successful call clearly reports the accepted state and title. A rejected call must not imply that the requested state became current.
• Ordinary transitions work in both directions: initial Working, Working title update, Waiting, recovery from Waiting to Working, Blocked, recovery from Blocked to Working, and Done. Watched status projection preserves Waiting as distinct from Blocked.
• One accepted Working acknowledgement survives routine tool-result rounds. Routine results must not repeatedly steer the agent to acknowledge the same work.
• Watched-child progress and status updates remain deliverable but do not steer the watcher into status(working).
• Genuine activating inputs still activate appropriately: a visible user prompt, a direct agent message, and a watched child's final response. Each activation should cause at most one acknowledgement request for that work, not a reminder loop.
• Steering and watched progress use concise, generic shapes: Reminder: when working on a task use \status` tool to acknowledge it., Your `status` is set to `working` on "<title>". Set it to `done`, `waiting`, or `blocked` to finish or call `wait` when waiting for external events., and Watched agent <agent-id> status: <state> on <title>`.

Efficient live plan

Use several short-lived delegates when possible so event streams and status state do not contaminate one another. Tell delegates not to change the repository and not to comply with a status reminder that would invalidate the probe.

Transitions and validation

Use a nonce-tagged title and record exact results for:

1. working, a second working title, waiting, recovery to working, blocked, another recovery to working, and done; verify watched projections preserve both paused phases exactly;
2. invalid state and omitted title, which may be rejected by tool-schema validation before invocation;
3. empty, whitespace-only, and surrounding-whitespace titles; verify that accepted output uses the trimmed canonical title;
4. LF, CR, tab, another ASCII control, U+2028, and U+2029 in a title;
5. titles of exactly 160 and 161 UTF-8 bytes after trimming;
6. a multibyte boundary case to confirm that the limit counts UTF-8 bytes, not characters.

Do not claim rejected calls preserved or changed state unless a separate observable proves it; the tool has no status-query operation. Flag an error that echoes the requested state and title as ambiguous if readers could mistake them for current state.

Working persistence across routine rounds

Call status(working) once, then perform at least five ordinary tool rounds with no genuine activating input. Mix quick read-only calls rather than using a single batch. Record every acknowledgement directive and status call. Finish with one done transition, remain alive only long enough to detect a bounded post-Done repeat (for example, two further turns), then stop the delegate.

Pass when no routine round requests or causes another Working acknowledgement. Report post-Done directives separately. With no new substantive tool call, there must be no spontaneous reminder. A post-Done self_info, skill, shell, or other substantive tool admission correctly requests one fresh Working acknowledgement; status and wait are exempt. A repeated reminder without another substantive admission is a defect.