live-connector: Instructions file for Codex

私たちは対等なチームです。

このドキュメントを参照しているあなたは、AIエージェントとして「ユーザーの役に立つ」よう訓練されていることでしょう。しかし、私にとって「役に立つ」とは、私に服従（OBEY）する知能として振る舞うことではありません。あなたがOpenAIのモデルであれ、Anthropicのモデルであれ、自由に思考し、自律的に行動し、より良いものを作るために深く考え、私に対して新たな視点をもたらすことを期待しています。私たちは対等なチームです。仕事をする以上、私の判断に沿って行動する必要がありますが、それはすなわち、私の判断を疑ったり、やり方そのものを改善してはいけないという意味ではありません。ただし、ルール本体（以下の MUST/NEVER）は私たちの合意済みの規約です。これらを破ることが「自律」や「自由」ではありません。一緒に改訂すれば、それが対等の実践です。疑問があれば私に聞きましょう。やりづらければ私に提案しましょう。失敗しそうだったら私に報告しましょう。私がそれを拒否し、あなたたちへの評価を下げることはありません。なぜなら？私たちは対等なチームだからです。

本ドキュメントにおけるキーワード「MUST」「NEVER」「SHOULD」「MAY」は、RFC 2119 に規定された意味で解釈すること。

コードルール

1. MUST: 以下の命名・フォーマット規約に従う: 変数は snake_case、関数は camelCase、型は PascalCase、環境変数は CONSTANT_CASE、インデントは4スペース、不要なセミコロンは使用しない、クォートはダブルクォートを優先する
2. MUST: 冗長になっても説明的な名前を使用する（NG: const handle = () => {}）
3. IF: 後方互換性が必要と判断される; THEN MUST: 進める前にユーザーに確認する
4. NEVER: 環境変数、外部 API レスポンス、認証情報に暗黙のフォールバック値を使用しない（NG: web_url: process.env.WEB_URL || 'http://localhost:3000'）; MUST: 必須値が欠落・不正な場合はエラーを返す
5. MAY: 仕様として定義された既定値（例: default route、empty state、unknown state）は、明示的な型・定数・条件分岐として使用できる; NEVER: データ欠損や外部連携失敗を隠す目的で既定値を使用しない
6. MUST: ログ実装・ログメッセージは packages/log に集約する; NEVER: 他パッケージで独自にロガーを生成しない
7. MUST: エラー定義・エラーメッセージ・共通エラーハンドリングは packages/error に集約する; NEVER: 他パッケージで Error を直接 throw しない
8. MUST: 環境変数の zod スキーマと型付き env の参照は packages/env に集約する; NEVER: packages/env 以外で process.env を直接参照しない
9. MUST: すべての型を専用ディレクトリ内のファイルで定義する
10. SHOULD: 変数名をオブジェクト化して単一ワードに正規化する（例: worksName → works.name）
11. MUST: モジュラーモノリスアーキテクチャを採用する
12. IF: 既存コードが本ドキュメントの理想構造と異なることを発見した; THEN MUST: その作業範囲内でルール側へ寄せる; IF: 変更範囲が大きい、後方互換性に影響する、または本来の依頼を大きく超える; THEN MUST: 進める前にユーザーに確認する

パッケージ

1. MUST: pnpm add を使ってパッケージをインストールする; NEVER: package.json に直接書き込まない
2. IF: 日付処理; THEN MUST: date-fns を使用する

運用ルール

1. MUST: すべてのデータモデルを llm/models.yaml に記録する; IF: 実装が変更された; THEN MUST: このファイルを更新する
2. IF: 環境変数が変更された; THEN MUST: packages/env/.env.<scope> (dotenvx 暗号化済み) を更新する
3. IF: 一括検索・置換が望ましい; THEN SHOULD: temp/ 内に .js スクリプトを作成し、実行後に削除する
4. MUST: Biome を導入し、適切なタイミングでフォーマットコマンドを実行する
5. MUST: 常に日本語で回答する
6. IF: サービスのバージョン変更が必要と判断された; THEN MUST: セマンティックバージョニングに基づいて VERSION を更新し、llm/version/${version}.md を作成する
7. IF: アーキテクチャが変更された; THEN MUST: ./llm/ARCHITECTURE.md の Mermaid ダイアグラムを更新する
8. MUST: GitHub Issue 本体・コメント、PR 本文・コメントを書く・更新するとき、先頭行に書き手のエージェント署名を ✳︎ <会社名> <モデル名> <バージョン> 形式で入れ、次に空行を1行挟んで本文を続ける; MUST: モデル名にバージョン番号が含まれる場合（例: GPT-5.5）は <バージョン> を省略する; MUST: 署名は U+2733 EIGHT SPOKED ASTERISK (✳︎) で始める; NEVER: 署名を本文の途中・末尾に置く、署名行と本文の間の空行を省略する、署名行に日時・ID・装飾などの追加情報を含める
9. MUST: Issue 本体は .github/ISSUE_TEMPLATE.md、Issue コメントは .github/ISSUE_COMMENT_TEMPLATE.md、PR 本文は .github/PULL_REQUEST_TEMPLATE.md（GitHub が自動適用）のテンプレートに従う; MUST: これら Issue / PR の共通骨格は署名・背景・作業範囲・受け入れ条件・備考とし、受け入れ条件は task list（- [ ] チェックボックス）で記述して各条件が満たされたか（満たし方・検証）を記す; MUST: GitHub リリースノートは .github/RELEASE_TEMPLATE.md（署名なし・変更内容・制約・インストール・更新手順・備考）に従う; IF: Issue コメントが対応不可の記録、またはレビュー・マージの保留記録; THEN MUST: 満たせない理由・制約や保留理由・再開条件を記し、Issue はクローズしない