Enforce agent-state UX for app→agent features (live task status, readable results) #13

Summary

When an agent builds app→agent (bi-directional) features, the UI it produces doesn't show the agent's state. The user had to keep telling the agent that they need real-time, proper updates on what the agent is doing. When the agent's result does arrive, it's rendered badly. In the report's screenshot, a long agent result ("Agent search: completed · 30s · Found an online copy…") is dumped into the narrow title column of a list row, so it wraps to one or two words per line and stretches the card down the page.

The creator skill already spells out the rules (skills/creator/SKILL.md, "The UI that queues work must show that work until it is done"):

• store the task id
• poll GET /api/_a2app/tasks/{id}
• render submitted / working / completed / failed
• show a "no agent is listening" hint after ~20 s
• show a list badge

Agents don't follow these rules reliably, and nothing catches it when they don't.

Proposal

Make it a gated requirement instead of advice:

1. Validate gate: when an operation calls trigger(...) with a capability, check that the View references the returned task id or follows /api/_a2app/tasks/ (or a progress field the agent writes onto the record). Fail with a pointer to the skill section if it doesn't.
2. walk-verify: add explicit checks for any feature that queues work:
   • every task state is visible
   • elapsed time shows while waiting
   • a "no agent listening" message appears when no bridge is up
   • the result renders in a readable block, not squeezed into an existing narrow column
3. UI kit: ship a reusable agent-task status component (state + elapsed + progress step + result summary) in the blueprint UI kits, so the default path is the good one.
4. Creator skill: state the result-rendering rule as well. Long agent output gets its own full-width, readable area (expandable or truncated, with links shown as links), not appended to the title cell.

Acceptance

An app whose button queues agent work can't pass validate or walk-verify unless the person can see, in real time, that the work is waiting, in progress, done (with a readable result) or failed.