[1395490241lhj-code]

Summary

The deploy.yml CI gate is currently blocking PRs against main, including #34. This PR has two independent commits, one for each blocker:

Commit	Scope	Purpose
1dc789e fix(deps): patch follow-redirects security advisories	package-lock.json +3/−3	Clears two high-severity advisories that fail npm audit --omit=dev --audit-level=high
f533d6d test(node22): avoid startup log deserialization failure	test/ai-conversation-lifecycle.test.mjs +15/−0	Works around a Node 22 test-runner bug that crashes the lifecycle test file in CI

Neither commit changes production code, package.json, the CI workflow, the Node 22/24 matrix, test concurrency or any test assertion.

1. follow-redirects 1.16.1 security update (1dc789e)

follow-redirects@1.16.0 is flagged by:

• GHSA-q3jh-wrc6-jgq8: array-form headers bypass cross-origin credential stripping
• GHSA-8r9p-f939-6h3c: sensitiveHeaders regex escaping can expose credential headers

The upstream fix is 1.16.1.

• Lockfile change: only the version, resolved and integrity fields of node_modules/follow-redirects change. The integrity value matches the npm registry's 1.16.1 dist. A field-by-field compare of all 122 lockfile entries shows this is the only one that changed.
• Why package.json is untouched: follow-redirects is transitive only. Its single dependent is the production dependency axios@1.20.0, which declares ^1.16.0, so 1.16.1 is in range.
• Unchanged: overrides (there are none) and the audit gate. No advisories are ignored.
• Upstream change: between 1.16.0 and 1.16.1 only two request-time paths change, array-form header normalization and escapeRegex. Load-time behaviour is the same.
• Runtime impact: /api/ai-conversation and /api/ai-chat use the openai SDK, which has no lockfile dependencies and does not go through follow-redirects. axios is used by the SSRF guard and media fetch, both with maxRedirects: 0 and manual hop validation, and by the vision OCR POST with default redirect handling.

2. Node 22 test-runner compatibility (f533d6d)

On this PR, the test (22) job failed twice (original run and one re-run). Both times the error was in test/ai-conversation-lifecycle.test.mjs:

failureType: 'uncaughtException'
error: 'Unable to deserialize cloned data due to invalid or unsupported version.'

The file has two tests. The first reported ok; the runner crashed before it could read the second test's result. No assertion failed. Node 24 passed every step.

Root cause. The Node v22.23.3 parent runner (FileTest#processRawBuffer) finishes one v8 frame and then reads the next 4 bytes as a length, without checking for the frame header first. This is nodejs/node#64061. If those bytes are test stdout whose 3rd byte is ≥ 0x80, the length comes out negative and the runner deserializes garbage. nodejs/node#64706 fixed this with >>> 0, and the fix is in v24 and v26. It has not been backported to v22.x; see nodejs/node#65934. The trigger here is the server.js startup line, 🍳 Kitchen Manager 全栈服务已启动，端口 0, which begins with the bytes f0 9f 8d b3. Only the lifecycle tests really listen() and print it. Whether it crashes depends on that line landing in the same pipe read as the preceding frame, which explains the intermittent CI history.

Change. Inside startRealServer only, console.log is wrapped so that a line starting with 🍳 Kitchen Manager gets a [server] prefix, which is ASCII. All other output passes through unchanged. The wrapper is installed before require(server.js), because the line is printed later from the listen callback. afterEach restores the original console.log, before the server-close await.

Local evidence. These were run on Node v26.12.0. Node 22 is not installed locally, so this is not a real Node 22 run.

• npm test: 1999/1999 pass, same test count as before. The lifecycle file passed 5 runs in a row.

• Captured the lifecycle file's raw child-v8 stdout before and after the change:

  • before: one text segment directly after a frame would yield a negative length on v22, namely the emoji line;
  • after: none would;
  • stdout is 11 lines in both cases, and only the two startup lines gained the prefix. stderr is identical.

• Replayed both captures through a line-for-line transcription of the v22.23.3 parseMessage/#processRawBuffer:

  Model	Before	After
  v22, whole stream in one read	reproduces the exact CI error	parses all 20 events
  v22, 5000 random reads coalescing 1–4 consecutive writes	3081 failures	0 failures
  v24.21.0 model	0 failures	0 failures

• A temporary failure-injection copy of the file, since deleted, confirmed that console.log is restored after a failing test and after a failure before listen.

Residual risk.

• Stdout bytes that mimic a full frame header can still break the runner, even on v24 (nodejs/node#66164). Current output contains none.
• The workaround can be removed once v22.x ships #64706.

Test plan

• Local npm test on Node v26.12.0: 1999/1999
• npm audit --omit=dev --audit-level=high and npm audit: 0 vulnerabilities (before: exit 1 with the two advisories)
• validate:recipe-packs / validate:recipe-pack-data pass
• Loopback smoke with the real axios 1.20.0 and follow-redirects 1.16.1:
  • same-origin redirect is followed
  • maxRedirects: 0 does not follow
  • Authorization is stripped on a cross-host redirect
• CI test (22): full suite, recipe validation and production audit on real Node 22
• CI test (24): full suite, recipe validation and production audit

Notes

• Independent of PRs iOS: fix bugs and logic issues found in the UX and functional reviews #31, Kitchen AI Phase 1a: tonight recipe recommendations with deterministic kitchen facts #32, fix: improve Kitchen AI reliability and conversation scrolling #33 and fix(server): diagnose Kitchen AI provider failures #34. Once this lands on main, re-running fix(server): diagnose Kitchen AI provider failures #34's CI should pick it up through the PR merge ref, with no rebase needed.
• Merging into main triggers a Render auto-deploy. That needs a separate approval.

🤖 Generated with Claude Code