[jackchuma]

What changed? Why?

Behavior-preserving cleanup of the /api/upgrade-config and /api/upgrades routes and their tests.

• upgrade-config/route.ts: the per-file map built the { fileName, displayName, ledgerId } object twice (success return inside the try, fallback with ledgerId: 0 after it). It now starts with ledgerId = 0, sets it on a successful parse, warns in an else branch on a parse failure, keeps the read-error warn in catch, and returns one object. Warn messages, ledgerId values, and response shape are unchanged.
• upgrades/route.ts: dropped .map(upgrade => ({ ...upgrade, network })). getUpgradeOption in src/lib/deployments.ts builds every Upgrade from baseInfo, which already sets network to the requested network on every return path, so the spread was a no-op in production.
• upgrade-config tests: the four invalid-network cases (.., foo/bar, main net, .) are one it.each with all four inputs and identical assertions. Added a test for the read-error fallback (previously untested), and the parse-failure test now also checks its warn message.
• upgrades tests: removed the includes zeronet when aggregating test and its beforeEach default mock. The sort test already returns a Zeronet task and asserts it in the aggregate; its HTTP 200 assertion moved into the sort test so a success-status check remains. The tagging test now asserts only the ready-to-sign filter, since the route no longer overrides network.

Interfaces removed: none.

Notes to reviewers

Found by the cleanup scanner. The duplicated returns came from 7c8298a; the network spread from dbe7f9e and was kept by 4bdeedd. Nothing suggests either was added for future work.

How has it been tested?

• npm test (14 suites, 172 tests), npm run lint, npx tsc --noEmit, npx prettier --check src all pass.
• The new read-error test passes against the original route and fails if the catch warn is removed.

Why this cleanup

• Production: +6 / -15 (net -9). Tests: +31 / -62 (net -31). Interfaces removed: none.
• A reader no longer has to compare two return literals in the upgrade-config map or notice that the parse-failure warn falls through to the fallback, skims one table-driven case instead of four copies, and no longer meets a beforeEach mock used by one test or a tagging test implying the upgrades route rewrites network.
• Keep-gate judge: remaining behavior is identical (same objects, key order, warn messages); the dropped spread was a no-op because every getUpgradeOption return builds on baseInfo; nothing removed points at future work; the related cleanups in two routes plus new read-error coverage are worth a quick review.

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[jackchuma]

Review round 1

Reviewers: cbhq-openai/gpt-6.1-sol (spec check: anthropic/claude-opus-5-5)

• Dropped in triage: [P2] getUpgradeOption network invariant pinned only on the README path — raised by both reviewer and spec checker. src/lib/deployments.ts:197-227 builds every return from baseInfo (which sets network), and src/lib/__tests__/deployments.test.ts already asserts network on the README path. Pinning the no-README and parse-error paths would add about 10 test lines to src/lib/__tests__/deployments.test.ts, outside this PR's files.
  Synced with main: 576d323 (already current)
  Validation: npm test (172 passed), lint, tsc, prettier on src: pass

🤖 Reply generated with Toshi

[0xth4nh]

Looks Good to Thanh's Toshi