Release: staging -> main (2026-04-14)

[github-actions]

Summary

Promotes staging into main.

• Source branch: staging
• Target branch: main
• Generated by npm run pr:promote

Included PRs

• chore: sync main into staging #495: chore: sync main into staging (@app/github-actions)
• Fix CodSpeed performance regression in validateMagicNumbers #497: Fix CodSpeed performance regression in validateMagicNumbers (@is0692vs)

Compare

• https://github.com/Hiroki-org/OpenShelf/compare/main...staging?expand=1

Greptile Summary

CodSpeed のパフォーマンス回帰を修正するため、validateMagicNumbers 内のマジックナンバー検出ループを、各シグネチャに対応するインライン if-else ブランチに展開しています。バイト比較のロジックは元の実装と完全に等価であり、機能的な問題は見当たりません。

Confidence Score: 5/5

• このPRはマージしても安全です。変更は機能的に等価なパフォーマンス最適化です。
• 全ての指摘事項はP2（スタイル・保守性）レベルであり、バグや機能的な問題は存在しません。バイト比較ロジックはMAGIC_NUMBER_MAPの元の実装と完全に一致しており、正確性に問題はありません。
• 特に注意が必要なファイルはありません。

Important Files Changed

Filename	Overview
apps/api/src/utils/file.ts	マジックナンバー検出のループをインライン if-else に展開してパフォーマンスを改善。論理的には元のコードと等価だが、MAGIC_NUMBER_MAP が部分的にしか使われなくなる保守性の懸念が残る。

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[validateMagicNumbers] --> B[Read first MAX_MAGIC_SIZE bytes]
    B --> C{PDF signature match?}
    C -- Yes --> D[detectedType = pdf]
    C -- No --> E{PNG signature match?}
    E -- Yes --> F[detectedType = png]
    E -- No --> G{JPEG signature match?}
    G -- Yes --> H[detectedType = jpeg]
    G -- No --> I{OLE signature match?}
    I -- Yes --> J[detectedType = ole-storage]
    I -- No --> K{ZIP signature match?}
    K -- Yes --> L[detectedType = zip]
    K -- No --> M[return false]
    D & F & H & J & L --> N{MIME_COMPATIBILITY check}
    N -- mismatch --> O[return false]
    N -- match --> P{PPTX?}
    P -- Yes --> Q[hasZipEntry check]
    P -- No --> R{PPT?}
    R -- Yes --> S[hasOleStream check]
    R -- No --> T[return true]
    Q & S --> T

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: apps/api/src/utils/file.ts
Line: 235-245

Comment:
**`MAGIC_NUMBER_MAP` との乖離リスク**

`MAGIC_NUMBER_MAP` はマジックナンバーの定義を持ち続けていますが、実際の判定ロジックはこの if-else チェーンに移されました。将来の開発者が新しいファイルタイプを追加する際、`MAGIC_NUMBER_MAP` にエントリを追加しても、対応する if-else ブランチを追加しないと **サイレントに検出スキップ**されます（`MAX_MAGIC_SIZE` の計算には使われるが、マッチングには使われないため）。

`MAGIC_NUMBER_MAP` の用途を `MAX_MAGIC_SIZE` のみに限定するか、コメントで両箇所の同期が必要であることを明示することを検討してください。

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "Merge pull request #495 from Hiroki-org/..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
open-shelf	Ignored		Apr 14, 2026 0:04am

[greptile-apps]

MAGIC_NUMBER_MAP との乖離リスク

MAGIC_NUMBER_MAP はマジックナンバーの定義を持ち続けていますが、実際の判定ロジックはこの if-else チェーンに移されました。将来の開発者が新しいファイルタイプを追加する際、MAGIC_NUMBER_MAP にエントリを追加しても、対応する if-else ブランチを追加しないと サイレントに検出スキップされます（MAX_MAGIC_SIZE の計算には使われるが、マッチングには使われないため）。

MAGIC_NUMBER_MAP の用途を MAX_MAGIC_SIZE のみに限定するか、コメントで両箇所の同期が必要であることを明示することを検討してください。

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/api/src/utils/file.ts
Line: 235-245

Comment:
**`MAGIC_NUMBER_MAP` との乖離リスク**

`MAGIC_NUMBER_MAP` はマジックナンバーの定義を持ち続けていますが、実際の判定ロジックはこの if-else チェーンに移されました。将来の開発者が新しいファイルタイプを追加する際、`MAGIC_NUMBER_MAP` にエントリを追加しても、対応する if-else ブランチを追加しないと **サイレントに検出スキップ**されます（`MAX_MAGIC_SIZE` の計算には使われるが、マッチングには使われないため）。

`MAGIC_NUMBER_MAP` の用途を `MAX_MAGIC_SIZE` のみに限定するか、コメントで両箇所の同期が必要であることを明示することを検討してください。

How can I resolve this? If you propose a fix, please make it concise.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 2 untouched benchmarks
⏩ 15 skipped benchmarks¹

---

_{Comparing staging (42d7d5b) with main (6e093cd)}

Footnotes

1. 15 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩