Plan: BLOCKED:PERSISTENT → status=gated#

Summary#

Change handlePersistentBlock to set status: 'gated' instead of status: 'blocked', pass 'gated' to the onPhaseBlocked hook, update TaskStatus type to include 'gated', update the hook's early-return logic for the new category, and add tests. No migration script needed — see Risks.

Files#

File	Action	Description
`src/internal-adapter/internal-adapter.service.ts`	modify	Change `status: 'blocked'` → `'gated'` and hook arg `'blocked'` → `'gated'` in `handlePersistentBlock` (lines 295, 305)
`src/hooks/phase-hooks.service.ts`	modify	Update `onPhaseBlocked` early-return to treat `'gated'` category same as `'blocked'` for refine/review phases (line 116)
`src/task-state/task-state.types.ts`	modify	Add `'gated'` to `TaskStatus` union type (line 12)
`src/internal-adapter/internal-adapter.service.spec.ts`	modify	Update test expectations for `handlePersistentBlock` to assert `'gated'` status and hook arg
`src/hooks/phase-hooks.service.spec.ts`	modify	Add/update test for `onPhaseBlocked` with `'gated'` category on refine/review phases

Steps#

In internal-adapter.service.ts line 295, change status: 'blocked' to status: 'gated' inside handlePersistentBlock.
In internal-adapter.service.ts line 305, change the fourth argument of onPhaseBlocked from 'blocked' to 'gated'.
In task-state.types.ts, add | 'gated' to the TaskStatus union type after 'blocked'.
In phase-hooks.service.ts line 116, update the early-return guard to also suppress label/comment for category === 'gated' on refine/review phases.
Update unit tests in internal-adapter.service.spec.ts to expect 'gated' in persistent-block scenarios.
Update unit tests in phase-hooks.service.spec.ts to cover 'gated' category behavior.

Verification#

npm run test — all unit tests pass with updated expectations
npm run lint — zero warnings
npm run build — compiles cleanly

Risks#

Migration script omitted: The issue requests a one-time migration for existing blocked rows. However, this codebase uses SQLite with TypeORM and has no migration infrastructure. The status column is a plain string with no enum constraint. Existing blocked rows from genuine error paths must remain blocked. A migration would need to distinguish BLOCKED:PERSISTENT-sourced rows from error-sourced rows — this requires checking WAL/event records for signal: 'BLOCKED:PERSISTENT'. Recommend: handle migration as a follow-up issue with a standalone script, or manually update the few affected rows via the control API's status-override endpoint.
Metrics aggregation already correct: metrics.service.ts line 114 already groups both blocked and gated into inProgressCount, so no metrics change needed.