[1395490241lhj-code]

Kitchen AI Reliability & Motion is stacked on PR #32: base claude/hopeful-volhard-9272e9, head claude/kitchen-ai-reliability. It fixes problems found during the first real use on an iPhone 17 Pro. It does not fix the production "AI 服务暂时不可用" outage. That outage has no proven root cause yet.

Commits:

• 20a0de2 fix(server): improve Kitchen AI upstream failure diagnostics
• 329cc50 fix(ios): stabilize Kitchen AI conversation and scrolling

11 files, +694/−11. There is no change to the six content blocks, the five proposals, the coordinator, the interpreter, the orchestrator, persistence, confirmation or undo.

⚠️ Read first

• The server patch only adds diagnostics. It does not fix the production AI outage. Production currently runs main: /api/ai-diagnostics/config reports renderCommit=5b6d2b09a4ca. The cause can only be established after this patch is deployed and Render's redacted ai_conversation_failed logs are read for a reproduced failure. Possible causes, none confirmed:
  • Gemini 429/timeout, then a Groq fallback that also fails (20 s timeout or 413 token limit);
  • Render cold-start 503s;
  • 4xx validation failures shown as "unavailable".
• requestSizeBytes counts only messages. It does not include the ~6,000 characters of tool definitions sent with every request, so it is not the full request size.
• The iPhone 17 Pro still runs bcca20a + de14ffd. This PR is not installed on any device.
• PR iOS: fix bugs and logic issues found in the UX and functional reviews #31's persistence protection (de14ffd, "run legacy data migration once so emptied data stays empty") is not in main and not in this branch. A read-only merge check shows this branch + iOS: fix bugs and logic issues found in the UX and functional reviews #31 and Kitchen AI Phase 1a: tonight recipe recommendations with deterministic kitchen facts #32 + iOS: fix bugs and logic issues found in the UX and functional reviews #31 both merge cleanly. Final integration must keep de14ffd, and any device build must be bcca20a + de14ffd + this PR.

Server: upstream failure diagnostics (20a0de2)

Problem. /api/ai-conversation caught every provider exception, logged only resultCode: provider_unavailable, and dropped the upstream error. 429, 413, timeouts and 5xx were indistinguishable in production logs.

Change. server.js and test/ai-conversation-stream.test.mjs only.

• ai_conversation_failed / ai_conversation_completed now also record:

  • primaryProvider, timeoutMs and requestSizeBytes (messages only, see above);
  • on failure: upstream status, reason (the upstream error code), timeoutSource and upstreamRequestId;
  • when a provider switch happens: fallbackReason (the first provider's code).

• Field values are validated, not only field names. The logger allowlist does not vet values, so:

  • status must be an integer from 100 to 599;
  • codes must be safe identifiers (at most 64 chars of [A-Za-z0-9_.-]), otherwise unrecognized;
  • request ids must be 8–128 chars of [A-Za-z0-9_-], otherwise they are dropped.

  Upstream error text, keys and conversation content are never logged. Tests assert this with hostile upstream values, for example a code that echoes the prompt and a request id containing spaces and a key fragment.

• Unchanged: provider routing, timeouts (45 s primary, 20 s fallback), the fallback rule, retries (maxRetries: 0, no client auto-retry), rate limiting, and /api/ai-chat.

How to read the logs after deploy:

Log shape	Meaning
durationMs ≈ 45000	primary timed out
attempt=2	a transient primary failure fell back to Groq
1–2 s duration	immediate rejection
no log line at the failure time	the request never reached the app (Render-level 5xx)

status, reason and fallbackReason then name the upstream cause.

iOS: conversation reliability and scrolling (329cc50)

Fixes for what the device run showed:

• A meal follow-up got prose instead of cards. 「今晚做什么」, sent after 「用快过期的食材做饭」, read only tonight's plan.

  • A whole short follow-up now inherits the meal intent, matched against the entire sentence: 换一个 / 换一批 / 再来一个 / 换个清淡的 / 推荐点简单的 / 今晚做什么 / 那明天做啥 / 还有别的吗 / 有没有其他的 / Anything else? / What else?
  • It only does so when one of the last three user questions was an explicit meal question.
  • Home only. Excluding inventory still withholds the shortlist. Planner is unchanged.

• System instructions. When recommending dishes, the model uses present_recipe_card, cites shortlist recipeIDs, keeps prose to one or two sentences, and does not claim freshness or quantity. When nothing fits, it says why briefly and gives one next step. The length rule applies only to dish recommendations; plan changes and other questions are answered in full.

• Failed retries stacked identical error rows. An older attempt of a retried turn is hidden once a newer attempt exists, if it carried only an error or was stopped empty (AIConversationTranscriptPresentation). This is presentation only: persisted history is unchanged, and a failed attempt with partial text, a card or an action outcome always stays.

• The transcript yanked readers back to the bottom on every streamed delta. Three onChange handlers could scroll in one update. Now (AIConversationAutoScroll):

  • one trigger drives at most one scroll per update;
  • a drag up to reread stops following, and later deltas leave the position alone;
  • a drag that dismisses the keyboard keeps the previous follow state;
  • a new user message, a running retry, or a different conversation resumes following. This does not depend on observing .preparingContext, so it still works if SwiftUI coalesces the send with .requesting or .streaming.

  No animation was added, and the existing scroll animation and Reduce Motion handling are unchanged (D-043).

Privacy regression checks

These are assembler tests that assert the actual domain reads, not just the intent function:

• New negatives. In a conversation that already asked what to cook, these read only tonight's plan, with no inventory and no shortlist: 我想换手机 / 推荐电影院 / 今晚做什么运动 / 今晚做什么运动好 / 换个话题 / 推荐一部电影 / 还有别的事吗 / 帮我推荐个电影 / "Anything else about my phone?". 谢谢 / 明天几点下班 / 今晚会下雨吗 inside a meal conversation stay unread too.
• Follow-up words without an earlier user meal question read nothing extra. A meal question older than the last three user turns does not carry over.
• The 24 earlier negatives (饭店推荐, 饭卡, 吃药, 菜馆, 菜单, 早餐店, 午餐会议, weather/theater, …) still hold.
• The instructions test asserts the full text reaches the model untruncated, and that the old blanket wording 「正文最多两三句」 is gone.

Validation

All iOS runs used xcodebuild through dev-sim-slot on the reserved simulator, iOS 27.2, with parallel testing off. Xcode MCP was held by another worktree. The tested tree is byte-identical to 329cc50; nothing changed after the final runs.

Suite	Result
iOS unit (ContextAssembler 58, Controller 74, AutoScroll 7, TranscriptPresentation 5)	144/144
iOS UI (AIConversationWorkspaceUITests 79 incl. test47 and all 4 StructuredBlocks variants, AIConversationAcceptanceUITests 4)	83/83
Server (ai-conversation-stream, -lifecycle, -turn-limit, ai-server-routes)	181/181

No new compiler warnings in the changed files.

How the UI result was reached:

• The first round was 80/82. The two StructuredBlocks AXXXL cases failed.
• A control run on clean bcca20a failed Light AXXXL with the same error. So this is a pre-existing PR Kitchen AI Phase 1a: tonight recipe recommendations with deterministic kitchen facts #32 red: at AXXXL the 继续调整 chips push the last card above the view, and the test helper only scrolled down.
• The helper now scrolls both ways. This is a test-only change.

About test47:

• test47_ScrollingUpDuringStreamingIsNotPulledBackAndASendFollowsAgain uses a DEBUG-only incremental stream of 40 pieces over about 10 s. It covers: dismiss the keyboard, scroll up mid-stream, position held after the stream ends, then send with the keyboard up and follow the new reply.
• The corrected test47 also passed on the pre-fix code, so the coalesced-update failure was not reproduced in real UI. The latestUserMessageID resume is a defensive fix.

Screenshots. test47 captured three screens, kept as local review evidence and not attached here:

• AutoScroll-1-ScrolledUpMidStream
• AutoScroll-2-StreamFinishedPositionHeld
• AutoScroll-3-SendFollowsWithKeyboard

CI's iOS tests workflow runs the whole unit target plus its default UI selection. That selection does not include AIConversationWorkspaceUITests. To recapture these screens in CI, dispatch it with ui_tests: KitchenManagerUITests/AIConversationWorkspaceUITests.

Not verified

• The production AI outage root cause. Getting it needs deploy approval and Render logs.
• Any physical device run of this PR, including scroll feel, keyboard and real streaming.
• The new instructions against the real models, i.e. whether cards appear reliably.
• Real VoiceOver listening and Reduce Motion runtime capture.
• The full iOS and full server suites locally. CI on this push is pending.
• /api/ai-chat's existing log values are not value-validated. That is pre-existing and out of scope.

Proposed, not implemented (needs decisions)

• The 库存 · 今晚计划 · 菜谱 chips read as "always read".
• 400/413 show as "unavailable" even though a retry cannot succeed.
• A failed turn cannot be retried after an app relaunch.
• Card and empty-state transitions (D-043 scope).
• Trimming tool definitions per entry point, which changes what the AI can do.

Merge order

1. Merge iOS: fix bugs and logic issues found in the UX and functional reviews #31 (which carries de14ffd) and Kitchen AI Phase 1a: tonight recipe recommendations with deterministic kitchen facts #32 into main in whatever order the owner picks. Keep de14ffd.
2. Retarget this PR to main and merge it.
3. Deploying the server diagnostics to Render needs explicit owner approval.

🤖 Generated with Claude Code