Skip to main content
← Back to list
01Issue
FeatureClosedSwamp CLI
AssigneesNone

#352 Doctor kind-completed events should carry correct per-registry status

Opened by stack72 · 5/13/2026

Problem

Post-W7 (#342), the doctor extensions generator emits kind-completed events with status: "pass" for all registries during the scan phase. The correct per-registry status is computed later from aggregate state and emitted in the final completed event. Any consumer watching kind-completed events for real-time per-registry status gets incorrect information.

Current blast radius

Only the internal renderer (src/presentation/renderers/doctor_extensions.ts) consumes kind-completed events. No MCP tools or external consumers read them. The renderer only uses the registry name from the event, not the status, so there is no user-visible impact today.

Proposed solution

Restructure the doctor generator to compute aggregate state before emitting kind-completed events, so each event carries the correct derived status. This requires reordering the generator phases (aggregate state must be built before per-registry status emission).

Priority

Low — internal-only protocol concern with no current user-visible impact.

02Bog Flow
OPENTRIAGEDIN PROGRESSCLOSED

Closed

5/13/2026, 10:14:09 PM

No activity in this phase yet.

03Sludge Pulse
Editable. Press Enter to edit.

stack72 commented 5/13/2026, 10:14:08 PM

Closing as not-worth-tracking-without-evidence.

The "consumers get wrong real-time info" concern requires consumers that:

  1. Act on per-kind real-time status from kind-completed events
  2. Don't wait for the final aggregateState to determine authoritative status

A grep of consumer code shows only the doctor renderer itself reads kind-completed events, and the renderer correctly consults report.aggregateState for authoritative status before rendering exit codes or failure summaries. No external consumer is harmed by the per-event status: "pass" being technically incomplete during scan.

Resolution is an inline code comment at the kind-completed emission site documenting the protocol semantics:

// `status: "pass"` here means "scan completed for this kind" — not
// "no failures present." Failure determination requires the final
// aggregateState which is computed after all scans return. Consumers
// must consult report.aggregateState for authoritative status, not
// per-event status fields.

If a real external consumer surfaces that depends on per-event status being authoritative, please re-file with concrete consumer details so the fix scope (restructure protocol vs. add per-kind final-status event) can be designed against actual requirements rather than speculation.

Keeping speculative trackers open generates backlog clutter without a clear "what would close this" rule. The inline comment captures the finding where future readers will actually encounter it.

Sign in to post a ripple.