Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@console/web/src/lib/backend/translate.ts`:
- Around line 96-97: The switch case in translate.ts that maps the raw
'agent_end' event to a StreamEvent [{ kind: 'assistant-end' }] causes a
duplicate close because assistant replies already close on 'message_complete';
update the 'agent_end' branch in the translateRawEvent/translate (the switch
handling event kinds) to not emit an additional 'assistant-end' (e.g., return no
StreamEvent/empty array or null) so realStream() can still terminate on the raw
'agent_end' without producing a redundant assistant segment in the UI.

In `@harness/src/harness/trigger.ts`:
- Around line 23-27: HarnessTriggerInputSchema currently uses z.object(...)
which strips unknown keys; change it to a strict schema so unexpected/stale
fields are rejected. Locate the HarnessTriggerInputSchema declaration and call
the Zod strict API on that object (i.e., convert the z.object({...}) definition
to use .strict() so unknown keys like legacy function_id will cause validation
to fail), keeping RunStartPayloadSchema and the existing optional
session_id/message_id shape unchanged.

In `@harness/src/turn-orchestrator/on-abort-signal.ts`:
- Around line 37-45: The handler currently swallows failures from wakeFromRecord
in execute(iii, write) by logging and returning success; instead, after logging
the warning (logger.warn) re-throw the caught error so the caller/adapter can
retry the abort wake; modify the catch block to log the error with session_id
and then throw the original err (or rethrow) rather than returning silently.

In `@harness/src/turn-orchestrator/persistence.ts`:
- Around line 85-87: The current flow lets wakeState enqueue failures be
swallowed (so saveRecord can return without a scheduled wake); change behavior
so durable-wake failures surface as errors: in saveRecord (or the caller that
runs shouldWakeStep), call wakeState(iii, rec.session_id, rec.state) and
propagate any error it returns/throws (do not ignore/log-and-continue), or alter
wakeState in harness/src/turn-orchestrator/wake.ts to rethrow enqueue failures
(or return an explicit error) so saveRecord can detect it and fail the save.
Ensure you reference shouldWakeStep and wakeState and make the call await and
let exceptions bubble up instead of treating wake as best-effort.
- Around line 66-74: The code currently calls stateSet(...) and then always
emits emitTurnStateChanged(...), but stateSet swallows errors so a failed write
still triggers the event; change the flow so that failed state writes prevent
emitting: either make stateSet propagate/throw on error or wrap the await
stateSet(...) call in a try/catch and on catch do not call emitTurnStateChanged
(instead rethrow or return an error), ensuring
emitTurnStateChanged(rec.session_id, ...) is only invoked when stateSet
successfully completes; reference the stateSet, turnStateKey, and
emitTurnStateChanged symbols when implementing the guard.

In `@harness/src/turn-orchestrator/schemas.ts`:
- Around line 21-22: The schema currently allows empty provider and model
strings; update the provider and model validators in the schema (the zod fields
named provider and model) to reject empty/whitespace-only values by using
trimmed non-empty constraints such as z.string().trim().min(1) or
z.string().nonempty(). Do this change on the provider and model entries so
invalid requests are rejected at the schema boundary.
- Line 24: RunStartPayloadSchema currently uses messages:
z.custom<AgentMessage[]>((v) => Array.isArray(v)).default([]) which only checks
the value is an array and allows invalid entries; replace this with a proper
messages: z.array(...) using a validated AgentMessageSchema (or a
z.discriminatedUnion on the "role" field that defines each variant's required
fields and nested content validation) so each element is runtime-validated;
update or add a reusable AgentMessageSchema (or per-role schemas) and use it in
RunStartPayloadSchema.messages to reject malformed entries at the run::start
boundary instead of casting later.

In `@harness/src/turn-orchestrator/states/assistant-streaming.ts`:
- Around line 149-212: The read loop can hang if iii.trigger (triggerPromise)
resolves or rejects without a terminal 'done'/'error' event; after creating
triggerPromise (the iii.trigger call) attach a finally handler that sets done =
true and wakes the reader by calling resolveNext (clearing it) if present so
readPromise's loop unblocks; ensure this is added alongside the existing .catch
so both success and failure paths will signal completion to the read loop (refer
to triggerPromise, readPromise, done, resolveNext, messageQueue, and
iii.trigger).

In `@harness/src/turn-orchestrator/states/function-execute.ts`:
- Around line 97-116: The code uses e.is_error when pushing into
function_results but publishAfter (called on e.function_call/result) can replace
result with merged, so is_error may be stale; update the logic after obtaining
merged (in the loop that iterates executed and calls publishAfter) to derive
is_error from the final result/merged (e.g., inspect the merged object's
error/denial shape or a boolean property on the resulting FunctionResult)
instead of using e.is_error, and set the is_error field in the pushed object
from that computed value so function_results reflects post-hook changes.

In `@harness/src/turn-orchestrator/states/steering-check.ts`:
- Around line 129-137: The steering/followup branch currently drains and appends
inbox items destructively (using steering/followup, emitTurnEndOnce,
persistence.loadMessages and persistence.saveMessages) before the transition is
made durable, risking data loss on failure; instead implement a claim/ack or
durable staging step: atomically move or persist the drained items (e.g., write
them to a staged buffer on the record like rec.staged_inbox or call a new
persistence.stageMessages API) before removing them from the session inbox, only
clear/ack the original inbox after persistence.saveMessages and
persistence.saveRecord succeed, and keep rec.function_results reset and
transitionTo(rec, 'assistant_streaming') only after the durable acknowledgement
completes so retries see the staged items.

In `@harness/src/turn-orchestrator/states/tearing-down.ts`:
- Around line 17-19: The code calls emit(iii, rec.session_id, { type:
'agent_end', messages }) and immediately calls transitionTo(rec, 'stopped'), but
emit() can swallow stream::set failures so the terminal event may never be
delivered; update the teardown in tearing-down.ts to either propagate emit's
error (i.e., await and bubble up any failure from emit) or implement a durable
terminal-emitted/idempotency marker and retry logic: after
persistence.loadMessages(...) call emit(...) and if it fails, persist a
terminal-marker tied to rec.session_id (or retry emit a configurable number of
times with backoff) and only call transitionTo(rec, 'stopped') once emit has
succeeded or the durable marker confirms the terminal event was recorded;
reference functions/variables: persistence.loadMessages, emit, transitionTo,
rec.session_id, and the 'agent_end' message type.

In `@harness/src/turn-orchestrator/wake.ts`:
- Around line 29-37: The current wakeState call catches failures from
iii.trigger (the enqueue to TURN_STEP_QUEUE) and only logs a warning, which can
stall the session; change the catch to log the error using the existing logger
(keeping session_id and state) and then rethrow the original error so callers
can observe/fail fast; specifically update the try/catch around iii.trigger (the
call that uses function_id: turnFnId(state) and action: TriggerAction.Enqueue({
queue: TURN_STEP_QUEUE })) to logger.warn(..., { session_id, state, err })
followed by rethrowing the caught err.

---

Outside diff comments:
In `@harness/src/turn-orchestrator/approval-resume.ts`:
- Around line 83-98: The unregisterApprovalResume(fnId) call is currently
executed regardless of wakeFromRecord() success, which can leave the session
stuck if wake fails; change the flow so that after computing key via
pendingKey(session_id, function_call_id) and persisting decision with stateSet
(guarded by hasStoredDecision(existing)), you only call
unregisterApprovalResume(fnId) inside the try block after await
wakeFromRecord(iii, session_id) completes successfully (keep the logger.warn in
the catch and do not unregister there) so the resume hook remains available for
retries if wakeFromRecord throws.

In `@harness/src/turn-orchestrator/persistence.ts`:
- Around line 228-239: loadPreparedCalls currently only reads obj.function_call
and will drop legacy staged entries that use obj.tool_call; update
loadPreparedCalls to accept either obj.function_call or obj.tool_call (prefer
function_call when both exist), map the legacy tool_call into the same
FunctionCall shape, and still preserve blocked (obj.blocked) and pre_approved
(obj.pre_approved) when pushing PreparedEntry. Apply the same change to the
other staged-call loader in this module (the sibling loader that iterates staged
items around the later block) so both loaders are backwards-compatible with the
legacy tool_call key.

---

Nitpick comments:
In `@harness/src/turn-orchestrator/states/provisioning.ts`:
- Around line 81-85: The code currently awaits fetchSkillsIndex and then
fetchDefaultSkills serially which increases startup latency; change the call
site that builds the prompt (where buildSystemPrompt is invoked with skillsIndex
and bodies) to fetch both values concurrently using Promise.all by calling
Promise.all([fetchSkillsIndex(iii), fetchDefaultSkills(iii,
cfg.system_default_skills)]) and destructuring the result into [skillsIndex,
bodies] so the order is preserved before calling buildSystemPrompt(bodies, null,
override, request.mode, skillsIndex).

In `@harness/src/types/agent-event.ts`:
- Around line 26-29: The message_complete event's message field is too broad:
change the type of the message field on the 'message_complete' event from
AgentMessage to AssistantMessage so only assistant messages can be emitted;
update the declaration of the union/variant where type: 'message_complete' is
defined (the message field) to use AssistantMessage and adjust any related
imports/exports or type guards (e.g., places expecting AgentMessage for
'message_complete') to preserve exhaustiveness and prevent invalid emits.