KNOWN-BLOCKED-ON-REFACTOR: Release workflow red, blocked on node-immybot#1 (SDK type-vs-API answer)

[asachs01]

Release workflow blocked — KNOWN-BLOCKED-ON-REFACTOR

immybot-mcp main Release workflow has been failing since the initial scaffold
at the Lint step (tsc --noEmit), with 70 pre-existing TS errors that prevent
the docker and release jobs from ever running. As a result, no :latest
image has been re-shipped to ghcr.io since the repo went red — meaning any
downstream bug-fix in immybot-mcp cannot reach customers until this is
unblocked.

Root cause

Two distinct patterns:

Pattern A (~37 errors, src/domains/*.ts) — accesses to fields that don't
exist on the @wyre-technology/node-immybot SDK's TypeScript types (across 6
types: Tenant, Task, MaintenanceSession, MaintenanceSessionSummary,
ScriptExecutionResult, TaskQueueStats). Whether the SDK type defs are
incomplete vs the actual immybot API response shape, or the consumer code is
wrong, is a domain-knowledge / SDK-ownership question. Filed upstream as
the documented blocker: wyre-technology/node-immybot#1

Pattern B (~20 errors, src/__tests__/*.ts) — discriminated-union access
on the MCP SDK content-block type ({type:"text";text:string}|{type:"image";...})
without narrowing. Mechanical fix in the consumer, bundled with the refactor
once the Pattern A answer lands (fixing Pattern B standalone leaves the
Pattern A errors and Lint stays red — no point doing it alone).

Not fixed because

The Pattern A question genuinely requires immybot API-spec knowledge that
isn't derivable from this repo or the SDK repo without someone who knows
what the immybot API actually returns on the wire. Fixing 37 errors blindly
would either drop legitimate field accesses (if the SDK is wrong) or paper
over real consumer bugs (if the consumer is wrong) — neither is acceptable.

Path to ship

1. wyre-technology/node-immybot#1 resolves → SDK type defs updated, OR
   consumer corrections identified.
2. Apply per-answer fixes + the bundled Pattern B narrowings.
3. Lint (tsc --noEmit) goes green → docker + release jobs first-execute
   on push-to-main → layer 2 verified (expect possible orphaned-ghcr-package
   class as observed on the mimecast-mcp rehab).
4. Iterate until the full Release workflow is green.
5. Re-ship :latest → downstream bug-fixes can ship.

Scope this issue tracks

Repo-level marker for the blocker so a contributor (or future-me) opening
this repo sees immediately why Release is red and where the dependency
lives. Will close when Release is fully green end-to-end.

(Filed as part of the fleet-wide *-mcp Release-backlog rehab; the bounded
sibling case wyre-technology/blackpoint-mcp#2 is the in-flight comparison.)