cs-build-audit-codebase

コードベースを監査し、修正計画を立てる

ユーザーが「アプリがめちゃくちゃです。問題点と対処方法を教えてください」と言ったときに使います。診断的で、言語に依存せず、証拠に基づいています。最後に、平易な英語でまとめた調査結果の一覧、リポジトリ内の FINDINGS.md、判定（再構築するか、そのまま修正するか）、カンバンタスクを作成します。

最初に読むもの： codespring スキルの references/project-state.md（どこからでも開始できる方法、5つの質問）、references/auditing-and-fixing.md（ここでの各手順の根拠）、references/analyze-codebase.md、references/pitfalls.md。次に、このスキルの references/specialist-briefs.md（そのまま使えるサブエージェント向けの指示書）と references/plain-english-writeup.md（成果物の構成と文体）を読みます。

スクリプト — 手作業で同等の処理をする代わりに、これらを実行します。チェック結果は毎回同じでなければなりません。scripts/check-repo.sh（このスキル：Git と成果物の状態確認）と、codespring スキルの scripts/fetch-project.sh、state.mjs、check-map.mjs（状態検出とマップ検証）を使います。すべて読み取り専用です。判断が必要な箇所は文章で記述します。

以下のスクリプトのパスは、このスキル自身のフォルダーからの相対パスです。 スキルは隣り合わせにインストールされるため、../codespring/scripts/… でコアスキルのスクリプトにアクセスできます。最初に一度だけパスを解決し（SKILL_DIR=$(dirname <this file>)）、その後は絶対パスを使います。作業ディレクトリはユーザーのリポジトリになるためです。

言語や技術スタックに依存しません。 このスキルとその参考資料に記載された、レート表、レポート、状態コードなどの具体例はすべて、一般化の元になった監査からのラベル付き実例であり、対象コードベースに当てはまる前提ではありません。パターンを読み取り、例そのものを探さないでください。

ガードレール： 対象コードベースは読み取り専用とします。例外は1つだけで、リポジトリのルートに FINDINGS.md を作成できます。ただし、必ず事前に許可を求め、コミットしてはいけません。ユーザー自身が実行しているアプリやサービスへのライブプローブは問題ありません。破壊的な操作は避けてください。

0. プロジェクトの現在の状態を検出する

状態検出スクリプトを実行します。手作業で数えず、毎回同じ結果を得てください（隣にインストールされた codespring スキルの scripts/ を使います）。

bash ../codespring/scripts/fetch-project.sh --out /tmp/cs-state   # read-only snapshot; prints the projectId
node ../codespring/scripts/state.mjs       /tmp/cs-state          # the one-line summary + booleans and counts
node ../codespring/scripts/check-map.mjs   /tmp/cs-state          # the machine-checkable map faults

1行の概要をユーザーに表示します。これにより、何を省略するかが決まります。

• リンクされていない → まずリンクします（チームのワークスペース内に置く必要がある場合は、ウェブアプリでプロジェクトを作成するようユーザーに伝えます — pitfalls.md）。
• すでにマップがある → そのまま使う前に評価します（以下の手順に従います）。どちらの場合も、機能を作成したり、「対象のマップを構築」したり、ここで mindmap features を実行したりしてはいけません。既存の主要機能とその ID を表示してから、監査します。
• FINDINGS.md がすでにある → 読みます。監査を新規に始めるのではなく、更新します。
• タスクがすでにある → 最も大きいタスク番号を記録します。番号をリセットせず、その続きから割り振ります。

書き込みを行う前に、必ずローカルの .codespring/config.json から projectId を読み取り、表示します。

0a. 既存のマップは使える状態ですか？ — 判断基準

「マップがある → そのまま使う」 では大ざっぱすぎます。使いものにならないマップは、それをもとに作成するすべてのノート、PRD、タスクの質を損ないます。CLI コマンドを含む完全版は、cs-build-import-codebase/references/target-map.md を参照してください。

1. マップはありますか？ ない → 後で cs-build-import-codebase（§10）によって作成されます。ここでは作成しません。
2. 使える状態ですか？ 件数、タイトルの重複、平坦化されたサブ機能、ノートの欠落は、（上記の）check-map.mjs で確認できます。残りはあなたが判断します。コア機能は4～8 個で、それぞれユーザーがサイドバーの項目として認識できるものか。サブ機能は、出力ドキュメントのセクションやフォーム項目のグループではなく、ユーザーが行うことになっているか。カードの説明は 1 文で、詳細はノートに記載されているか。自動チェックをすべて通過したマップでも、理解しにくいことがあります。
3. 使える状態 → そのまま使います。 ノートを更新し、タスクを追加します。決して作り直しません。
4. 修正可能（おおむね正しいが、少し問題がある）→ その場で修正し、変更内容を伝えます。 codespring feature update <subId> --parent <coreId> で親を変更し、codespring feature delete <dupId> --yes で重複を削除し、codespring feature update <id> --title "..." で名前を変更します。
5. 修正不可能（混乱を招くほど間違っている — コア機能が極端に多い、出力セクションが機能として扱われている、一貫した構造がない）→ 修復を試みないでください。 理由を明確に説明し、クリーンなマップを備えた新しい CodeSpring プロジェクトを推奨します。古いプロジェクトは履歴として残します。2 つ目のプロジェクトを作成する前に、必ず明示的な確認を得てください。黙って作成してはいけません。

⚠️ 1 つのアプリに 2 つのプロジェクトがあると後で混乱を招くため、意図的な選択であることを説明する必要があります。また、ユーザーにはどちらのプロジェクトが現在の正規プロジェクトなのかを伝えなければなりません。実例では、コア機能が 13 個あるインポートは使いものにならず、クリーンな 6 機能のマップを備えた 2 つ目のプロジェクトに置き換えましたが、どちらも残っています。project delete はないため、これは取り消せません。1 つのアプリに 2 つのプロジェクトがある状態で作業を始める場合は、何かを書く前にどちらが正規プロジェクトなのかを確認してください。

1. ユーザーと監査の範囲を決める（簡潔に）

リポジトリのパス、アプリの起動方法、アプリの目的、置き換える既存製品の有無、すでに判明している不具合を確認します。何を最も知りたいのかも尋ねてください。実際の監査では、所有者自身の 3 つの質問（「異なる領域で間違っているのか？」「データベースをどう読み取っているのか？」「なぜ一部のレポートのほうがよく見えるのか？」）をもとに監査の方向性を決め、それぞれから主要な発見が得られました。

以下の 3 つの質問も確認してください。それぞれ、発見の意味を変えるためです（§2）。

• アプリに実際のユーザーや有料顧客はいますか？ これだけで再構築を見送る判断につながる可能性があります（§9）。結論を出すときではなく、今尋ねてください。
• 現在、このリポジトリでほかの人も作業していますか？
• アプリは機能が完成していますか、それともまだ開発中ですか？

最初に監査の方針を明示してください。目的は、すでに動いているものを適切に動作させることであり、機能を追加することではありません。 auditing-and-fixing.md §4a を参照してください。

2. 調査とリポジトリ／デリバリーの監査（まず自分で実施）

ほかのすべての調査結果に前提を与えるため、担当を分担する前に実施します。コマンドは specialist-briefs.md §6 を参照してください。以下を確認します。

• ローカルクローンはリモートより古いですか？ git fetch を実行し、ローカルの HEAD と origin/<branch> を比較します。遅れている場合は、その旨を伝え、監査の前に更新するかどうかを確認します。 古いクローンを監査すると、すでに修正済みの問題を指摘する可能性があります。（実際の監査では、本番環境から 2 回のマージ分遅れていました。）
• サーバー側のソースコードはリポジトリ内にありますか？ それともホスティングダッシュボードにしかありませんか？ 後者の場合は、重大な全損リスクとして指摘し、正確なバックアップコマンドを伝えます。
• ブランチ／PR の構成、デプロイが何らかの自動チェックによって制御されているか、またはマージすると本番環境へ反映されるのか、CI の有無、.gitignore が適切か、履歴にシークレットが含まれているか（含まれていない場合も報告）、ステージング環境があるか、それともすべてのセッションが本番環境に接続するのかを確認します。
• 技術スタックの説明をここで整え、サブエージェントごとに再調査しなくて済むようにします。

2a. コードベースは常に変化します — まずスクリプトを実行する

bash scripts/check-repo.sh --repo <abs repo path> [--paths <suspect files…>]

読み取り専用です（git fetch が変更するのはリモート追跡参照のみです）。調査結果の対象となるコミット、リモートより何コミット遅れているか、その未取得コミットが変更したファイル、各リモートブランチとその日付および作成者、最近の作成者、作業ツリーに変更があるか、自動チェックが存在するかを表示します。終了コード 2 は、クローンが遅れていることを意味します。

実際の監査でこれが検出した事例： リモートブランチが 12 個、所有者が main に直接コミットし、別の担当者が並行して作業中で、監査対象のクローンは 3 コミット遅れていました。しかも、最新のコミットが監査対象そのもののファイルを変更していました。

そのうえで：

• 遅れている場合は、何コミット遅れているかを伝え、監査の前に更新するか確認してください。 1 行で伝え、説教はしないでください。古いクローンを黙って監査してはいけません — 古いコードに基づく指摘は、すでに修正済みかもしれません。
• リモートブランチを列挙し、現在進行中の作業を報告してください。 すでに置き換えられた作業に対して指摘を書かないようにします。
• 正確なコミット SHA を、レビュー日付の横のヘッダーにある FINDINGS.md に記録してください。 調査結果はそのコミットのスナップショットであり、それ以外の何ものでもありません。
• 今、リポジトリでほかの人も作業していますか？ 確認してください。はいの場合、修正には専用ブランチを使うよう勧め、マージ競合の対応が必要になることを明確に伝えてください。
• 機能は完成していますか、それともまだ開発中ですか？ まだ開発中なら、マップにはコードにまだ含まれていない予定モジュールが抜けている可能性があるため、機能一覧を確定する前に、まだ実装されていない予定を所有者に確認してください。 実際の失敗例：何にもリンクされていなかったため、監査で 4 つのページが別製品だと結論づけましたが、実際には同じ製品の未完成モジュールでした（§6a、ルール 5）。
• 監査中にリモートが更新された場合は、すべてをやり直すのではなく、公開しようとしている個々の指摘を再確認してください。

Git の知識がないことを前提とし、所有者に説教しないでください。 技術に詳しくない所有者はブランチを理解していないことが多く、監査や再構築の最中でも main に直接コミットします。何をするのか、なぜそうするのかを 1 行で伝えてください — 「あなたの main へのコミットと私の作業がぶつからないよう、fixes というブランチで作業します」 — そして、履歴が常にきれいで直線的であることや、main が保護されていることを前提にしてはいけません。

3. アプリを実行して操作する

最も成果につながる手順です。省略したり、コードを読むだけで代用したりしてはいけません。 アプリを起動するかサーブし、主要な操作フローを実際に試し、コンソールとネットワークパネルを確認し、空・ゼロ・負数・極端な値・大文字小文字の違う入力を試し、データが実際にどこに保存されるかを調べてください。

実際の監査では、入力を消すと古い数値のままレポートが固まることを発見し、中核となる計算がネットワークリクエストを一切行わないことを確認して監査全体の方向性を見直し、認証のバイパスだと疑われていたものが、実際にはラベル付きのサンプルモードであることを突き止めました。実行してみることで、バグを発見するのと同じくらい、誤った告発を防げます。

4. 専門家を並行して参加させる

1 回のメッセージで、同時に起動してください。各専門家は読み取り専用とし、完全に自己完結した依頼内容を渡し、ほかの専門家の情報を見せないでください。独立性が証拠になります。依頼内容は references/specialist-briefs.md にあります。

セキュリティ／認証 · データベース／スキーマ · 中核ビジネスロジック · フロントエンド／UX／機能していない操作要素 · アーキテクチャ／スケーラビリティ

アプリに応じて、競合製品との比較、ユーザージャーニーと障害のマップ、データの出所の確認などの領域を追加してください。すべての指摘には file:line または再現用コマンドと、証拠ラベルを付けてください。CONFIRMED（実行した／該当行を直接読んだ）、INFERRED（実行せずに推論した）、UNVERIFIED（疑いがあり、何を確認すればよいかを記載）。ラベルも引用もない指摘は削除されます。

専門家が作業している間も、アプリの操作を続けてください。あなたは 6 人目のエージェントであり、意見の相違を解決する役割を担います。

5. 特定の欠陥カテゴリーを重点的に調査する

auditing-and-fixing.md §4 に記載されている項目です。気づくことを期待するのではなく、意識して調査してください。

• 古くなったハードコードの参照データ — 有効期限が切れても検知する仕組みがないまま、レート、価格、しきい値などがソースコード内にリテラルとして記述されている。
• 乖離した重複ロジック — 重複箇所の一覧を作成し、コピー同士が「現在」一致しているか、過去に不一致だったことがあるかを確認します。また、メインのエントリーポイントが実際にどのコピーを読み込むかも確認します。
• エラーが表面化しない失敗経路 — エラーがゼロ、空のオブジェクト、古い画面、または成功メッセージに変わってしまう経路です。「値がない状態」と「失敗」が同じように見えてはいけません。
• ブラウザー内にしか存在しないデータ — または、バックアップも警告もないまま、1 台のマシンにしか存在しないデータです。
• 検証できない通貨・精度の主張 — ソフトウェアが断言しているものの、自ら確認できないすべての事柄です。

6. 見出しとなる数値は自分で検証する

サブエージェントが出した最大の数値をそのまま伝えてはいけません。独自に再現してください。2 つ目の方法（ロジックを一時的なハーネスに切り出す）や、実際に動作するアプリを使って確認します。実際の監査では、どちらの方法でもセント単位まで一致しました。それによって、見出しに示す金額をクライアントに安全に提示できました。両方が一致した場合は、報告書にもその旨を記載してください。専門家同士の矛盾を解消してください。後から得られた、より多くの情報に基づく確認結果が以前の結果を上回る場合は、両方をそのまま提出するのではなく、修正内容を記録します。

6a. 次に自分自身を監査する — 実際に誤りが生じたのはここです

CONFIRMED / INFERRED / UNVERIFIED のラベルが適用されるのは、サブエージェントの出力だけです。実際の監査では、オーケストレーター自身による要約を確認する仕組みがなく、すべての誤りはそこで入り込みました。 詳しい実例は auditing-and-fixing.md §3a を参照してください。4 つのルールは次のとおりです。

1. 測定値には、その範囲を同じ文で明記します。 「3 つのキーで 45 バイト」 は 1 ページで測定した値でしたが、アプリ全体では 15 個のキーを使っていました。
2. サブエージェントの見出しとなる主張を繰り返す前に、それを証明するコマンドを 1 つ再実行します。 「税率表が 2 つのエンジンのコピー間で乖離している」 という記述は、diff で税率表のバイト列が完全に一致しており、別の関数が乖離しているとわかったときに書かれたものです。その結果、読者を誤ったファイルへ誘導しました。
3. アプリのほうが優れていると主張する場合、同じ文で「できないこと」も明記します。 アプリが既存のものより「先を行っている」と称したことで、その機能の簡単な部分しか解決していない事実が隠れていました。
4. 専門用語は、使う文の中で説明するか、別の表現に置き換えます。 「バージョン管理された税率表を保存済みファイルに記録する」 → 「レポートを保存するときに、使用した税率の年度も保存します。そうすれば、後で税率を修正しても、すでにクライアントに提示した内容は変わりません。」
5. コードベースの一部を対象外と結論づける場合。 4 つのページは、何からもリンクされておらず、別のスクリプトを読み込んでいたため、「別製品」と判断されました。根拠そのものは事実でしたが、結論は誤りでした。git log を見ると、これらのファイルは最初のインポート以降変更されていない一方、関連ファイルは毎週変更されていました。また、オーナーもその部分のワークフローをまだ整理する必要があると述べていました。これらは同一製品の未完成モジュールでした。ルール：コードベースの一部を対象外と結論づける前に、その git 履歴を確認し、オーナーに尋ねます。 参照されていないコードは、外部のものではなく未完成の可能性があります。ファイルごとに git log --format="%ad %s" -- <path> を実行するのは簡単かつ決定的で、ファイルの一覧には scripts/check-repo.sh --paths <files> を使えます。

必須の手順：§8 に何かを書く前に、見出しとなる主張を列挙し、それぞれの具体的な根拠を明記します — コマンド、file:line、または自分で操作した画面です。根拠を示せないものは削除するか、未検証と明記します。 リストを実際に書き出してください。サブエージェントではなく、自分自身の作業を確認する唯一の方法です。

7. すべてを3つの分類に分けます

提案ではなくルールです（auditing-and-fixing.md §4a）。監査の基本方針は拡張ではなく修正です。通常の目標は、機能を充実させることではなく、何かを稼働させることです。

1. 問題 — 現在、壊れている、または誤っているものです。これが作業対象であり、タスクになる唯一の分類です。
2. 後で追加できるもの — 実際に不足しているものの、意図的に保留するものです。独立したセクションに記載し、タスクリストには絶対に含めません。
3. 追加する価値がないもの — 質問が再び持ち上がらないよう、その理由も記載します。

機能の提案は、「ついでにこれも」のようなものも含め、タスクリストに入れてはいけません。「これが足りない」は分類2、「これがあるのに誤った答えを返す」は分類1です。

7a. 将来のアイデアの置き場所 — 今のところ、ほかにありません

CodeSpring には機能、メモ、PRD、カンバンタスクがあります。「後で作るかもしれないもの」を置く場所はありません。また、そうしたものをタスクにしてはいけません。タスクリストは作業を確約したことを意味するため、保留中のアイデアがボードに載っていると、誤って実装されるか、ボードの信頼性が損なわれます。

暫定ルール — 毎回これを使ってください： 将来のアイデアは、リポジトリ内の FINDINGS.md に、理由を添えて1行ずつ、明示的な見出しを付けた2つのセクションに記載します。

• 「後で追加できるもの — 今は意図的に追加しない」 — 保留する理由と、後で追加する価値があるかどうか。
• 「追加する価値がないもの」 — 質問をここで終わりにする理由。これにより、再び持ち上がらなくなります。

どちらのセクションにある内容も、タスク、マップ上の機能、PRDにはなりません。この方針を文書内で一度、はっきり明記してください。これを FERB にプロダクト上のギャップとして報告してください。明らかに確約ではないものとして扱える、第一級のアイデア用スペースがありません。

8. 平易な英語で調査結果を書く

構成と文体の詳細は references/plain-english-writeup.md にあります。譲れない要件は次のとおりです。

• 小学3年生程度の読みやすさを目安にします。 箇条書きは短くし、問題ごとに具体例を1つ挙げます。
• 実社会での影響の大きさで順位を付けます。金銭への影響、またはクライアントの信頼への影響が大きいものから並べます。
• ユーザー向けの文章では、ファイルパス、行番号、専門用語を使いません。 データベースのマイグレーションが何か知らない人にも、すべての調査結果が理解できるようにします。専門用語を使う場合は、同じ文の中で説明します。（「保存ファイルに記録されたバージョン管理済み税率テーブル」はこの条件を満たしません。「レポートを保存するときに、そのレポートで使用した年の税率も保存してください。そうすれば、後から税率を修正しても、クライアントにすでに表示した内容は変わりません」は条件を満たします。）
• 良い点も記載し、変更してはいけないものとして明示します。
• 将来のアイデア用に、明示的な見出しを付けた2つのセクション（§7a）を設けます。各項目は、理由を添えて1行で記載します。見出しは 「後で追加できるもの — 今は意図的に追加しない」 と 「追加する価値がないもの」 です。
• 調査結果が基づくコミットを、レビュー日とともにヘッダーに記載します。調査結果はスナップショットです（§2a）。
• 検証しなかったことと、それを検証する方法を記載して締めくくります。

確認してから、リポジトリのルートに FINDINGS.md を作成します。すでに存在する場合は、内容を維持したまま更新し、ユーザーが編集した箇所はそのまま残します。絶対にコミットしないでください。 品質基準と各セクションの構成については、references/plain-english-writeup.md を参照してください。

9. 判定 — 作り直すか、現状のまま修正するか

基本は現状のまま修正することです。作り直す場合は、その理由を示す必要があります。 ユーザーにも自分自身にも、はっきり伝えてください。アプリのアーキテクチャ全体を作り直すのは、大規模でリスクの高い作業であり、ほとんどのコードベースにとって間違った選択です。 置き換えられないロジックがほとんどない小規模なアプリには適しています。たとえば、小さな静的 HTML アプリは作り直しの妥当な候補ですが、それ以外はほとんど当てはまりません。作り直しを過剰に勧めないよう、自分に言い聞かせてください。困り果てたユーザーは書き直しを求めます。それに同意するのは簡単ですが、正しい選択とは限りません。欠陥の一覧が長いことは、作り直す根拠にはなりません。

判断のゲート — 表を見る前に、これを確認してください。単独で再構築に拒否権を行使できるためです

アプリに実際のユーザー、または有料顧客がいますか？

• いる場合 → コードの状態がどれほど悪くても、現在のアプリを修正することを強く推奨します。 再構築には移行と切り替えが必要で、新旧両方のバージョンが並行して存在する期間も生じます。稼働中のビジネスでは、そのリスクを受け入れられない場合があります。
• 稼働中のユーザーがいる状態で、再構築が本当に避けられない場合は、並行稼働計画が必要です。旧アプリを稼働させたまま新アプリを並行して構築し、明確な切り替え手順とロールバック計画を用意します。作業を始める前に、ユーザーがこれを理解し、受け入れている必要があります。
• 落とし穴をはっきり伝えてください。 通常、これは2つ目のリポジトリ、または長期間維持するブランチを意味します。また、複数のリポジトリにまたがってアプリの複数バージョンを管理すると、すぐに混乱します。 原則として同じリポジトリ内のブランチを使ってください。 別のリポジトリを使うのは、技術スタックが完全に変わり、1つのリポジトリで両方を管理できない場合に限ります。
• 「まだユーザーがいない」ことは、再構築を推奨する理由にはなりません。拒否権をなくし、表の判断に委ねられるだけです。

判断材料	再構築を支持	現在のアプリの修正を支持
現在のアーキテクチャで、アプリに必要な機能を実現できますか？	いいえ — 不足しているのは構造的な要素です（サーバーがない、アカウントがない、データの保存先がないなど）。また、現在の構成には追加できません	はい — 不足しているものは、既存の構成に追加できます
置き換えのきかないドメインロジックはどれくらいありますか？	少なく、切り分け可能 — きれいに取り出して移行できます	多い、または分散している — 価値のある知識がアプリ全体に広がっており、取り出せません
全体の規模はどれくらいですか？	小さい — ページ、ルート、画面が少なく、書き直しの規模を把握できます	大きい — ルート、マイグレーション、連携機能が多数あり、書き直しの範囲が際限なく広がる可能性があります
リファクタリングを保護するテストや CI はありますか？	関係ありません — コードをリファクタリングするのではなく、置き換えるためです	大いに役立ちます — リグレッションを検出するテストスイートがあれば、現在のアプリを安全かつ低コストで修正できます

点数としてではなく、全体を見て判断してください。再構築を行うには、ゲートを通過し、かつ最初の行の回答が「いいえ」である必要があります。 アーキテクチャで必要なものを実現できるなら、コードがどれほど醜くても現在のアプリを修正してください。醜いことと、形が合っていないことは同じではありません。

実際の事例に基づく、両方の判断例です。リポジトリにバックエンドがなく、アカウントもなく、データは1つのブラウザー内に保存され、まだ稼働中の顧客はいない静的 HTML アプリ。総コード量は約8,800行で、置き換えのきかないドメインロジックは約470行だけでした → 再構築（その470行は意図的に移植します）。一方、実際の認証、133件のマイグレーション、約142件の認可ポリシー、数百のルートを備え、深刻なセキュリティ上の問題がある Next.js アプリ → 現在のアプリを修正し、再構築は決して行わない。これらの問題はすべて、現在の構成のまま修正できるためです。

提示する内容：推奨事項、ゲートへの回答、判断を決定づけた2つか3つの材料、それに従う場合の正直なコスト。再構築の場合は、書き直すのではなく移植する部分に加え、アプリが稼働中であれば、並行稼働計画とロールバック計画も示してください。また、どちらの判断でも価値の高い作業を挙げてください。実際の事例では、バージョン管理されていなかったバックエンドのバックアップと、最初のテストスイートの作成でした。どちらも再構築を必要としませんでした。

10. マップへ引き継ぐ

cs-build-import-codebase を呼び出し、調査結果、判断、および既存のマップが階段のどの段に位置づけられたか（§0a）を渡してください。どちらの判断の場合も、これは修正後の目標マップ、つまりアプリがあるべき姿を構築します。また、既存のマップを重複して作成するのではなく、維持または修正します。ここでマップを構築しないでください。マップを構築するコードパスは1つだけです。

11. カンバンタスクを作成する

タスクの作成は cs-build-import-codebase §7 の中で行います。ここに機能 ID があるためです。ここで再実装しないでください。あなたの役割は、クリーンな入力を渡し、結果を確認することです。

指摘事項ごとに、バケット1の指摘事項のみを引き渡してください。それぞれに、重大度（Critical → urgent、High → high、Medium → medium、Low → low）、証拠ラベル、ファイル参照、該当するコア機能を含めます。バケット2とバケット3はレポートに残し、タスクリストには含めないでください。

次に、判定に応じて適切な形式になっていることを確認します。

• 再構築 → 仕様に沿って構築するタスクに加え、見つかった具体的な欠陥を引き継ぐ、独立した「避けるべき間違い」タスク一式を作成します。これにより、欠陥の再発を防ぎます。監査を先に行う理由は、この2つ目のタスク一式にあります。これがなければ、引き継ぎは失敗です。
• その場で修正 → 欠陥ごとに1つのタスクを作成し、欠陥がある場所を記載します。説明には ファイル参照を含めてください（ユーザー向けのテキストには含まれていませんが、エージェントが対応するにはタスクに必要です）。

未検証の指摘事項は、そのラベルを維持した調査タスクにします。確信のある修正タスクにしてはいけません。

12. 検証してから報告する

目視で済ませず、チェックを実行してください（auditing-and-fixing.md §9）。

bash ../codespring/scripts/fetch-project.sh --out /tmp/cs-verify
node ../codespring/scripts/check-map.mjs   /tmp/cs-verify --expect-core <the count you intended>

このチェックでは、コア機能の数、平坦化されたサブ機能がないこと、機能や PRD の重複がないこと、コア機能ごとにノートが1つあること、すべてのタスクが機能と重大度に紐付いていることを検証します。終了コードが0以外の場合は実際の失敗です。報告する前に修正してください。その後、差分を簡潔に報告します。作成 N 件、更新 N 件、スキップ N 件と記載し、プロジェクトリンク https://v2.codespring.app/project/<projectId> を示してください。

適切な結果とは

• アプリを実際に実行し、コードを読むだけでは得られなかった指摘事項が少なくとも1つあります。
• すべての指摘事項に file:line またはコマンドを引用し、CONFIRMED／INFERRED／UNVERIFIED のラベルを付けています。見出しの数値は個別に再現されています。
• 見出しに記載する主張は、記述する前にすべて証拠とともに列挙されています。測定値にはすべて対象範囲が明記され、サブエージェントが実際に見つけた内容以上に強い主張はありません。
• 監査の 前に クローンをリモートと比較し、指摘事項の根拠となるコミットを明記しています。また、リポジトリにほかに誰が関わっているか、アプリが完成しているかをユーザーに尋ねています。
• Git／CI／デプロイの設定を監査し、バックエンドがバックアップされているか、デプロイを阻止する仕組みがあるかをユーザーに伝えています。
• ユーザー向けの指摘事項は平易な表現で、コストの大きい順に並び、ファイルパスを含んでいません。また、壊れている点だけでなく、良い点も明確に説明しています。「競合製品より優れている」機能が、依然として何を実現できていないかも含めています。
• 問題点、後から追加できる項目、追加する価値がない項目を分けています。タスクリストには問題点のみを含め、将来のアイデアは、名前が指定された2つの FINDINGS.md セクションに記載しています。
• ユーザーの有無について確認し、回答を得たうえで、理由とともに判定を示しています。また、ユーザーがいない かつ 必要なものを実現するアーキテクチャが本当に存在しない場合を除き、「その場で修正」を選んでいます。
• CodeSpring 内で何も重複させていません。既存のマップを維持するか、その場で修復し、明示的な確認を得た場合にのみ、2つ目のプロジェクトを作成しています。