Render broker checkpoints as Slack-native model/harness progress

[arieldiaz]

Problem

Slack currently shows the native <App Name> is typing... indicator while a turn runs. Humanware OS also configures a separate progress-draft label, but broker routing, harness/model selection, normalized checkpoints, the Slack-native assistant status, and the session ledger are not yet one coherent path. Harness commentary can therefore leak into ordinary reply text or remain invisible instead of becoming concise progress.

Goal

Give Liv and Max one harness-neutral, bounded progress interface across Cursor/Grok, Codex/Sol, and future OpenCode/Pi/OpenRouter profiles.

The execution broker emits structured public progress events. The session ledger is canonical. The Slack adapter renders those events through assistant.threads.setStatus; long multi-step work may additionally use Slack-native task cards. Harnesses never publish directly to Slack and raw chain-of-thought, commands, private paths, secrets, or arbitrary model prose are never used as status text.

Spec

• Define a normalized public checkpoint schema with at least phase, label, profile, harness, model, reasoning, status, timestamp, and sourceEventId.
• Use a small allowlisted phase vocabulary such as routing, loading_context, planning, executing, verifying, packaging, and delivering.
• Record every checkpoint once in evidence/sessions/events/; derive session Markdown and console views from the same event.
• Render the current checkpoint under the Slack composer with assistant.threads.setStatus. Slack owns placement and the app-name prefix.
• Clear status on final delivery, explicit failure, cancellation, timeout, and no-reply.
• Rate-limit/coalesce updates; short turns should show at most the initial routed profile and final response.
• Keep one delivery owner. Cursor, Codex, and future harnesses return checkpoint events to OpenClaw and never call Slack directly.
• Preserve explicit failures and confirmed delivery semantics.
• Consider chat.startStream task cards only for genuinely long or multi-step work; do not turn every chat into a plan UI.

Proposed rendering

• Max is routing to Codex · Sol (low)…
• Liv is loading the relevant context…
• Max is running checks…
• Liv is preparing the artifact…

Delivery plan

• Spec the normalized checkpoint contract and privacy rules.
• Implement broker/harness adapters for Cursor and Codex.
• Implement the Slack status renderer and cleanup paths.
• Persist and project checkpoint events in the canonical session ledger.
• Add unit/integration tests and production canaries.
• PR, CI, squash merge, deploy, and evaluate on both Liv and Max.

Evals

• Liv default Cursor/Grok low shows the effective profile before model work.
• Max default Codex/Sol low shows the effective profile before model work.
• A first-turn profile override updates status without an extra model-routing turn.
• A mid-session harness/model switch changes the next status and persists for the following turn.
• A three-intent request produces bounded phase updates and one complete final response.
• Cursor and Codex tool/checkpoint events normalize to the same Slack wording and ledger schema.
• Short answers do not spam status updates.
• Long work can render task progress without exposing raw commands, paths, private context, or chain-of-thought.
• Failure, timeout, cancellation, no-reply, and gateway restart always clear stale status.
• Exactly one final Slack response is delivered and confirmed; no duplicate harness delivery.

Relationship

Follow-up to #38. Keep this as a separate Issue → Spec → PR → Deploy → Eval change after the unified broker cutover is verified with genuine Slack ingress across representative existing threads.