hasNumberContextField defined away from sibling helpers

hasStringContextField and hasBooleanContextField are grouped together around line 350. Defining hasNumberContextField ~124 lines later, right before its single use site, breaks the pattern and makes it harder to discover when adding future event types. Move this block up to sit alongside the other two helpers.

This is a comment left during a code review.
Path: src/hooks/internal-hooks.ts
Line: 474-479

Comment:
**`hasNumberContextField` defined away from sibling helpers**

`hasStringContextField` and `hasBooleanContextField` are grouped together around line 350. Defining `hasNumberContextField` ~124 lines later, right before its single use site, breaks the pattern and makes it harder to discover when adding future event types. Move this block up to sit alongside the other two helpers.

How can I resolve this? If you propose a fix, please make it concise.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

errorCode not surfaced in hook context

AgentTurnEndHookContext only carries success: boolean, so hook consumers can detect that a turn failed but cannot distinguish error codes (e.g. ACP_TURN_FAILED vs ACP_SESSION_INIT_FAILED). If any subscriber needs to branch on failure kind or log structured error info, consider adding an optional errorCode field while the shape is still easy to extend.

This is a comment left during a code review.
Path: src/hooks/internal-hooks.ts
Line: 463-466

Comment:
**`errorCode` not surfaced in hook context**

`AgentTurnEndHookContext` only carries `success: boolean`, so hook consumers can detect that a turn failed but cannot distinguish error codes (e.g. `ACP_TURN_FAILED` vs `ACP_SESSION_INIT_FAILED`). If any subscriber needs to branch on failure kind or log structured error info, consider adding an optional `errorCode` field while the shape is still easy to extend.

```suggestion
export type AgentTurnEndHookContext = {
  success: boolean;
  durationMs: number;
  errorCode?: string;
};
```

How can I resolve this? If you propose a fix, please make it concise.

Defer hook dispatch off turn thread

recordTurnCompletion is intended to be fire-and-forget, but triggerInternalHook(...) is invoked immediately while building the argument to fireAndForgetHook. Because triggerInternalHook awaits handler(event), any hook implemented as a synchronous function will run inline before the promise is detached, adding user-visible latency to ACP turn completion (especially for CPU/file-heavy handlers). This makes agent:turn:end capable of blocking the turn lifecycle despite the fire-and-forget wrapper.

Useful? React with 👍 / 👎.

Thanks for the review. To clarify — the pattern here matches how message-related hooks are fired in deliver.ts and dispatch-from-config.ts (both use fireAndForgetHook(triggerInternalHook(...))), not all hooks in the codebase. bootstrap-hooks.ts and compaction-hooks.ts correctly use await triggerInternalHook where blocking is intentional.

The key point still holds: triggerInternalHook is async and returns a Promise immediately — the for...await loop inside only runs in subsequent microtasks. fireAndForgetHook detaches that promise, so no handler code can block the caller. No change needed.