Release readiness review (v0.5.3 -> TARGET origin/main@7ff108b606cc646fdc000f9a788a1199b5438014)

This is a release readiness report done by $final-release-review skill.

Diff

v0.5.3...7ff108b

Release call:

• 🟢 GREEN LIGHT TO SHIP No concrete runtime, packaging, or test blocker surfaced; targeted core/realtime approval suites passed locally and the remaining risk is release-note/docs clarity around the new rejection-message flow.

Scope summary:

• 118 files changed (+6647/-4324); most churn is docs/sidebar/translated docs, with one concentrated runtime feature in packages/agents-core and packages/agents-realtime plus pnpm/workflow dependency bumps.

Risk assessment (ordered by impact):

1. RunState schema advances to 1.7 in a patch release
   Risk: 🟡 MODERATE. Mixed-version or rollback environments can produce 1.7 run-state payloads that an older SDK will not resume, so the durable-state boundary should be explicit in release notes even though the normal upgrade path is covered.
   Evidence: The feature stores per-call/sticky rejection messages inside serialized approvals and bumps CURRENT_SCHEMA_VERSION from 1.6 to 1.7; new tests cover restoring older 1.6 payloads into this release, but I did not find downgrade coverage or release-note text beyond the generic feature summary. Local targeted suites passed (235/235 tests), so this is a communication risk rather than a confirmed runtime regression.
   Files: runState.ts#L54, runContext.ts#L6, runState.test.ts#L613, reject-message-parameter.md#L1
   Action: Add one release-note sentence stating that serialized run states written by this release use schema 1.7; pass when the published notes make the resume-version boundary explicit for anyone running mixed versions or considering rollback.

2. User-facing guides do not surface the new per-call override path
   Risk: 🟢 LOW. Users can use the feature successfully, but guide readers may miss that state.reject(..., { message }) / session.reject(..., { message }) is now the most direct way to control rejection text and that it takes precedence over toolErrorFormatter.
   Evidence: The runtime now documents and implements message?: string on both reject APIs and the example uses it, but the authored guides still steer readers toward alwaysReject or toolErrorFormatter only. The gap is informational; the relevant core/realtime tests passed locally.
   Files: runState.ts#L668, realtimeSession.ts#L1169, human-in-the-loop.mdx#L34, running-agents.mdx#L174, build.mdx#L222, computer-use-hitl.ts#L143
   Action: Add a short guide note and snippet showing reject(..., { message }) and stating that a per-call message overrides toolErrorFormatter; pass when at least the human-in-the-loop and voice/realtime guides expose that precedence explicitly.

Notes:

• git fetch origin --tags --prune resolved BASE_TAG=v0.5.3; TARGET was origin/main at 7ff108b606cc646fdc000f9a788a1199b5438014.
• Working tree was clean during the review (## main...origin/main).
• I ran targeted local verification:
  NODE_ENV=test pnpm exec vitest run packages/agents-core/test/runContext.test.ts packages/agents-core/test/runState.test.ts packages/agents-core/test/runner/mcpApprovals.test.ts packages/agents-core/test/run.test.ts
NODE_ENV=test pnpm exec vitest run packages/agents-realtime/test/openaiRealtimeBase.test.ts packages/agents-realtime/test/realtimeSession.test.ts
  Both commands passed (235 tests total).
• I assumed the target commit already passed the repo’s full CI / $code-change-verification stack, per the skill instructions.