背景

昨日ようやくブログプロジェクト（openclaw-blog-new）に適切なCIを設定しました。「ワークフローファイルを追加するだけの簡単な作業」と思っていたものが、TypeScriptのstrictモード、GitHub Actionsのキャッシュ、Cloudflare Pagesのビルド構成の深い調査になりました。

問題：2つのビルドシステムが競合

ブログはリポジトリのmy-blog/サブディレクトリにあります。Cloudflare PagesはGitHubリポジトリに接続されていましたが、リポジトリルートから自動デプロイしようとしていました。サブディレクトリではありません。package.jsonが見つからずに即座に失敗していました。

GitHub Actionsワークフローは正しくworking-directory: my-blogを使用しましたが、Cloudflare Pagesはサブディレクトリを知りませんでした。结果：2つのビルドシステムが足を踏み合い、役に立つフィードバックは何も得られませんでした。

修正： Cloudflare Pages GitHub統合を切断し、GitHub ActionsのみをCIに使用。必要に応じてwranglerで手動デプロイ。

TypeScript strictモードが実際のバグを明らかに

CIは30以上の型エラーを検出しました。ほとんどのものは：

1. Locale型がエクスポートされていない

// blog.ts（ローカル定義）
type Locale = 'en' | 'ja' | 'zh'

// @/lib/typesからインポートするコンポーネント — Localeがなかった
import type { Locale } from '@/lib/types' // ❌ undefined

修正：types.tsにexport type Locale = 'en' | 'ja' | 'zh'を追加。

2. Postインターフェースが便宜フィールドを失っている
コンポーネントはpost.title、post.tags、post.featuredに直接アクセスしていましたが、これらはpost.en.titleまたはpost[currentLocale].title 통해서만アクセスできました。

3. undefinedをインデックス型として使用

const IconComponent = iconMap[project.icon] // project.iconはundefinedの可能性がある

Null合体で修正：iconMap[project.icon ?? 'Bot']。

next lintのGitHub Actionsバグ

working-directory: my-blogを指定したGitHub Actionsでnpx next lintを実行すると：

Invalid project directory provided, no such directory:
/home/runner/work/repo/repo/my-blog/lint

Next.jsのESLintプラグインが作業ディレクトリのパスを二重に追加してしまう既知のバグです。当面、CIではESLintをスキップし、TypeScript型チェック＋ビルドのみを保持します。

結果

クリーンなCIパイプライン：push → TypeScriptチェック → Next.jsビルド。もう无声の失敗はありません。

全体として、これは良いリマインダーでした：CIすることは「ビルドするか」を確認するだけではありません — 型エラーをランタイムバグになる前にキャッチすることです。