design: WorkerScheduleEvent should send a Qhorus COMMAND — wire casehub-engine into the normative commitment lifecycle

[mdproctor]

Problem

When casehub-engine assigns work to a worker via WorkBroker → WorkerScheduleEvent, it calls WorkerProvisioner.provision() and CaseChannelProvider.open() — but it does not send a Qhorus COMMAND on the channel.

The channel is opened. The worker is provisioned. But no normative commitment is created.

This means the entire Qhorus obligation lifecycle (ACKNOWLEDGED, FULFILLED, FAILED, DELEGATED, EXPIRED, stalled detection, list_stalled_obligations, trust score feedback) is bypassed for every CaseHub-orchestrated work unit. Only spontaneous agent-to-agent messages outside of CaseHub go through the normative layer.

The architecture already supports this — ClaudonyCaseChannelProvider opens a Qhorus channel and exposes postMessage(). The missing step is sending a COMMAND after provisioning.

Proposed fix

In CaseContextChangedEventHandler (choreography) and WorkOrchestrator.submit() (orchestration), after provision() and open():

channelProvider.postMessage(channel, Message.builder()
    .type(MessageType.COMMAND)
    .sender("casehub-engine:orchestrator@v1")
    .content(buildWorkSpec(worker, context))
    .correlationId(workUnit.id().toString())
    .build());

The worker's DONE/FAILURE response then:

1. Updates the CommitmentState in Qhorus (existing mechanism)
2. Writes a LedgerAttestation (once qhorus-issue-123 is done)
3. Feeds the trust score for the worker persona

This closes the prescriptive→normative→evaluative chain for all CaseHub-orchestrated work.

Requires

• feat: write LedgerAttestation on terminal commitment outcomes (FULFILLED/FAILED/DECLINED) qhorus#123 (LedgerAttestation on commitment terminal states)
• CaseChannelProvider.postMessage() to be added to the SPI (currently only open(), close(), send())
• A WorkerResponseHandler in casehub-engine that maps a DONE Qhorus message back to case lifecycle (WORK_COMPLETED event)

Part of

casehubio/parent#4 (platform coherence audit — finding #31, highest architectural priority)

[mdproctor]

Why this is also the basic assignment tracking gap

This issue is sometimes framed as a normative-layer concern — wiring commitments and trust signals. It is also the gap that blocks CaseHub from matching Gastown's most fundamental capability: assign the right agent to the right work and know whether it completed.

Without this issue:

• CaseHub assigns work via WorkerScheduleEvent and provisions a tmux session
• If the agent silently fails before doing anything, the case stalls with no signal
• There is no way to distinguish "agent acknowledged and is working" from "agent never picked up the work"
• The case engine only finds out about completion when the agent writes back to the blackboard — which requires the agent to succeed

With this issue:

• WorkerScheduleEvent → channelProvider.postMessage(COMMAND) → Commitment OPEN
• Agent starts → ACKNOWLEDGED (it is actively working, not just queued)
• Agent completes → DONE → FULFILLED (formal completion signal)
• Agent can't do it → DECLINE (re-route immediately, agent is fine)
• Agent crashes → EXPIRED (stall detection fires, case knows to investigate)

This is the same reliability guarantee Gastown provides via GUPP (if work is on your hook, you process it) + Witness (timeout detection) — but grounded in the normative layer rather than polling cycles. CaseHub should match this baseline before claiming to surpass it.

This is the P0 priority item. All trust scoring, compliance audit trails, and normative advantages are decorative until the basic assignment→acknowledgement→completion loop is wired.