Follow-up to the #2653 audit, and the one item there that is better
deleted than described.
## Why delete rather than annotate
`resolveEffectiveWorkflowIdSync` **has no callers.** Verified across
every `.ts`/`.tsx` in `packages` (excluding `dist`): only its own impl,
the `store.ts` import and public method, and one comment naming it. Not
exported from the core index, not referenced by any test.
It is also **wrong**. It reads `getTaskWorkflowSelection` — the sync
selection reader that has returned `undefined` unconditionally since the
PG cutover — so it always resolved `resolveCapacityPoolId(undefined)`:
the default pool for every task, regardless of workflow. The binding
capacity path reads the selection asynchronously inside its transaction
and does not use this.
That combination is the argument. A dead function is clutter; a dead
function that returns a **plausible wrong answer** is a trap. The next
person to need "which capacity pool is this task in?" would find a
public method with exactly the right name, call it, and get default-pool
behavior with no signal that anything degraded. #2653 documents it, but
documentation loses to autocomplete.
## Provenance of the claim
greptile's P2 on #2653 corrected my first draft, which called this a
live capacity collapse — it isn't, precisely because nothing calls it. I
verified the no-callers claim myself before accepting, and this PR is
the logical end of that correction: if it is unreachable, it should not
exist.
## Removed
- the impl in `task-store-helpers.ts`
- the `resolveEffectiveWorkflowIdSync` public method on `TaskStore`
- the import specifier in `store.ts`
- the now-unused `resolveCapacityPoolId` import (its only use was the
deleted function)
- updated the `workflow-definitions.ts` comment that named it
## Verification
core / engine / dashboard typechecks clean · eslint clean on both
touched files · `pnpm --filter @fusion/core build` exit 0 · **`pnpm
test:gate` green (487 + 71)**.
The engine and dashboard typechecks are the ones that matter here:
removing a public method from `TaskStore` would surface immediately in
any consumer that called it, and neither reports anything.
## Census
Unchanged (776 / triage 5) — no guards added or converted.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
174eb22534