実装要件（フォルダ構造 + ログ）は何をしますか？

分析済みの要件の構築を開始する際に適用する一般的な指示です（分析フェーズには使用しません）。これは RV2-054-132-019_ Integración proceso ADG（CONSUBANCO）で初めて適用されたパターンに基づいて再構築されています。 このスキルはポータブルです。使用するプロジェクトやクライアントに関係なく同様に適用され、§0のアンカールールに従います。

0. これが存在する場所（プロジェクト間のポータビリティ）

このプロンプトは、絶対パスや特定のクライアント名を想定していません。使用されるすべてのプロジェクトで有効なアンカールールは次のとおりです。

そのプロジェクト/クライアントのすべての要件をグループ化するフォルダが常に存在します（リテラル名は異なる場合があります: Req\、Requerimientos\、またはユーザーが新しいプロジェクトで初めて作業する際に示すその他の名前）。その中に、要件ごとに1つのサブフォルダがあり、そのコードで命名されます（例: RV2-054-132-019、場合によっては_<短い名前>が続きます。例: RV2-054-132-019_ Integración proceso ADG）。
このドキュメントの他のすべてのもの（README.md、Compartidos\、EchasXC\、SCRIPTS\...）は、その特定の要件のサブフォルダを基準としています。上にあるコンテナフォルダの名前は関係ありません。コンテナフォルダの名前を毎回尋ねる必要はありません。プロジェクトにすでに存在する場合（Req\ または Requerimientos\）はそれを使用し、まだ存在しない場合（新しいプロジェクト）は、作成する前にユーザーに名前を尋ねてください。
新しい個別の要件（§10参照）は、そのコンテナフォルダの下に独自のサブフォルダを持っている（または必要とする）ことで識別されます。同じクライアント/モジュールに属していても、既存の別の要件のフォルダ内に決して配置されません。

具体的なツリー（§1〜§4のすべては要件フォルダから直接ぶら下がり、このツリーが示すレベルより上にも下にも何も配置されません）:

Req\                                     (または "Requerimientos\"、プロジェクトが既に使用している名前)
└─ RV2-054-132-019_ Integración ADG\     ← 要件フォルダ（§0）、他のすべてのアンカー
   ├─ README.md                         ← §1、ログ
   ├─ Compartidos\                      ← §2、HU/画像/証拠/キー
   ├─ EchasXC\                     ← §4、Claudeが生成する正式な成果物ではないすべてのもの
   │  └─ SCRIPTS\                       ← §3、Claudeの作業フォルダ（ルートではない）
   │     ├─ ORG\                       ← ロールバック、独自の番号付け
   │     └─ MOD\
   │        ├─ ALTERS\                 ← テーブルのみ
   │        ├─ SP\                     ← ストアドプロシージャのみ
   │        ├─ FN\                     ← 関数のみ
   │        └─ VI\                    ← ビューのみ
   ├─ SCRIPTS\                          ← §3、ユーザーがキュレーションするルートフォルダ。許可なく触らない
   ├─ Analisis_Impacto_[CÓDIGO].docx    ← 分析フェーズの成果物（要求された場合）
   ├─ Estimacion_tiempos_[CÓDIGO].xlsx
   └─ Plan_Implementacion_[CÓDIGO].docx

1. 変更ログ — 要件フォルダのルートにある `README.md`

1つのファイルで、ライブであり、何かが構築/変更されるたび、未解決の質問が解決または追加されるたび、または何かのステータスが変更されるたびに更新されます。固定構造:

要件のコードと名前 + "最終更新: YYYY-MM-DD" を含むヘッダー。
これは何か — 要件の2〜4行の概要。
全体のステータス — すでに構築されているもの — フェーズ/モジュールごとに1つの箇条書きで、構築済み/部分済み/保留中をマーク。
アーキテクチャ（各要素の場所） — 画面パス、主要SP（フラグ付き）、ジョブ、主要テーブル、設定ファイル。データベースアクセス（サーバー、データベース名、ユーザー、パスワード）はここや他のファイルには文書化しません。ポータル/プロジェクトによって異なり、ユーザーが必要なときにパスワードとともに提供します（§7参照）。
保留中 — 「お客様への質問」（解決したら ~~text~~ で打ち消し線を付け、削除しない）と「保留中の開発」に分けられます。
変更ログ — セッション/日付ごとに1エントリ（**YYYY-MM-DD (短いタイトル)**）、最新のものを上に。内容: 実際に見つかったギャップ/バグ、決定事項とその理由、変更されたファイル、ユーザーが行う必要があること（スクリプトの実行、再コンパイル、画面でのテスト）。

Analisis_Impacto_[CÓDIGO].docx や Plan_Implementacion_[CÓDIGO].docx を置き換えるものではありません（これらは分析フェーズの成果物です）。このREADMEは構築のライブステータスです。

大きくなりすぎた場合のローテーション — README.md が約200KBに近づいたり超えたりした場合は、追加を続ける前に古いセッションをアーカイブします（実際に発生したケース: README.md が256KBを超え、読み取りツールが開けなくなった）。仕組み: 古いログエントリを新しいファイル README_historico_AAAA.md（年ごと、または必要に応じて）に移動し、アクティブな README.md には最新の約10〜15セッションと、アーカイブされた内容の2〜3行の概要のみを残します（アクティブなものだけを読んでも連続性を失わないようにするため）。その他のセクション（これは何か、全体のステータス、アーキテクチャ、保留中）は決してアーカイブされず、常にアクティブなファイルに残ります。ローテーションされるのはセッションログのみです。

2. `Compartidos\` フォルダ

クライアント/外部ベンダーと共有されるインプットまたは証拠となるすべてのもの（コードは除く）: HUとその付属資料、ドキュメントから抽出された埋め込み画像/スクリーンショット、キー（PGP/証明書）、データマッピングファイル、受け取った、または第三者（例: CDC）に送信されたテストファイル。

Compartidos\ に現在の要件に関係のないトピックのドキュメントが表示された場合（例: 「統合プロセスADG」フォルダ内の「ログ/監査」HU）: 2つの安易な出力のいずれも想定しないでください。つまり、そこにあるという理由だけでこの要件の証拠として扱うことも、独自に無視したり移動したりすることもしないでください。ユーザーに、次の3つのケースのどれであるかを尋ねてください:

誤配置 — 別のフォルダに属しており、誤ってコピーされた。
新しい個別の要件で、まだ独自のフォルダがない — この同じ構造でフォルダを作成し、現在のものとデータベースオブジェクト/画面を共有する場合は、両方の「関連要件」（§10）に文書化する。
意図的に1つのクライアントフォルダにグループ化された要件セット（このパターンの先例は、QA合格メールテンプレートに存在し、「要件セット」を明示的に考慮しています）— その場合でも、コードごとにサブフォルダを作成する方が適切かどうかを確認する。

3. スクリプトフォルダ — `SCRIPTS\ORG\` および `SCRIPTS\MOD\`

要件フォルダには2つの異なる SCRIPTS フォルダがあります: <requirement>\SCRIPTS\（ルート）と <requirement>\EchasXC\SCRIPTS\。Claudeが構築する際に各スクリプトを置いていく作業フォルダは EchasXC\SCRIPTS\ です。 ルートフォルダ SCRIPTS\ はユーザーが手動でキュレーションし、彼が良いと判断したものを EchasXC\SCRIPTS\ から昇格させます。ユーザーが明示的に要求しない限り、そのルートフォルダには触れないでください。

MOD\ — オブジェクトタイプごとのサブフォルダ。グループ化はせず、各サブフォルダは独自の独立した連続番号を持ちます（相互に番号を共有しません）:

MOD\ALTERS\ — テーブルのみ（CREATE TABLE / ALTER TABLE）。
MOD\SP\ — ストアドプロシージャのみ。
MOD\FN\ — 関数のみ（CREATE FUNCTION）。
MOD\VI\ — ビューのみ。
専用フォルダがないオブジェクトタイプ（インデックス、トリガー、ジョブなど）が表示された場合は、どこに入れるか、または「似ている」フォルダに入れるかを想定するのではなく、ユーザーにフォルダの名前をどうするか尋ねてください。（以前に実際に発生したエラー: 関数が最初に SP\ に、次に ALTERS\ に配置され、ユーザーが専用の FN\ を作成するよう要求するまで続きました。）
すべての命名パターン: 変更される既存のオブジェクト → N_NOMBRE_MOD.sql; 完全に新しいオブジェクト（データベースに存在しない）→ N_NOMBRE_NEW.sql。

ORG\ — 変更されるオブジェクトのロールバック（_NEW にはここに対応するものはありません。新しいもののロールバックは単に削除することであり、キャプチャする以前の状態はありません）。既存のオブジェクトに触れる前に、データベースに現在存在する現在の定義を抽出し、ここに保存します。そのファイルがロールバックです。

ORG\ は MOD\ の数値的なミラーではありません。 そう想定するのは簡単ですが、誤りです。これらは独立した番号付けを持っています。それ自体の中でカテゴリごとに番号が付けられることさえあります（例: 依存関係を尊重して1回のパスですべての MOD\ALTERS を統合したロールバック、および触れた各SPの個別のロールバック）。「MODと同じ番号」を想定する前に、ORG\ の番号付けスキームについてユーザーに確認してください — これを誤って想定したために1回修正されました。
オブジェクトに触れる/デプロイするたびに、何が移動されたかを明確にするために、どのオブジェクト（名前）かをユーザーに明示的に通知します。

このセクションのスクリプトに関する一般的なルール:

DDLは常に冪等であること（IF NOT EXISTS / COL_LENGTH(...) IS NULL）。
別の新しいSPを呼び出す新しいSPは、依存関係と同じファイル/バッチで定義し、後のファイル番号では定義しないこと。
後で増分スクリプトを「統合」/クリーンアップする場合（後で個別のALTERを介して追加された列を元のCREATEに折り返す）: バックアップ用のALTERは、すでに完全なCREATEの下にそのまま残します（両方のパスが共存し、一方を選択しません）。対応するORGは、オブジェクトの完全な DROP をすでに行っている場合は変更する必要はありません。列ごとにロールバックする場合は、順序を確認してください（ロールバックで列に触れる前にインデックス/制約を削除し、作成時に最終的なNULL許容性を設定した後に作成します）。

4. 成果物ではない作業資料 — `EchasXC\`

Claudeが構築をサポートするために生成するが、クライアントやチームに正式に納品されないすべてのもの（検証クエリ、手動テスト、テクニカルシート、下書きメール）: Compartidos\ や正式な成果物から分離されたサブフォルダ EchasXC\ に配置します。

5. エンコーディング — 決してファイルに既に確立されているものを変更しないこと

アクセント付きのファイル（.aspx/.aspx.vb/.master/スクリプトなど）を編集する前に、宣言されているから、または file がそう報告するからといって、UTF-8であると想定しないでください。 レガシーポータルの古いファイルの中には、実際には内部がISO-8859-1/Windows-1252（アクセントが単一の高位バイト）であるものがあり、標準の Edit/Write はファイル全体をUTF-8としてデコード/再書き込みします。ファイル内の（編集箇所の近くだけでなく）既存のアクセントはすべて、保存された瞬間に、黙って恒久的に文字化け（U+FFFD、ブラウザでは "ï¿½" または同様のものとして表示されます）に変換されます。

このタイプのファイルに触れる前に、実際のエンコーディングを確認してください（file archivo.aspx。注意: すでに破損しているファイルは、実際にはそうでなくてもクリーンな "UTF-8" を報告する場合があります）。
ISO-8859-1の場合は、PowerShell経由で [System.Text.Encoding]::GetEncoding("ISO-8859-1") を使用して編集します。生のバイトをそのエンコーディングでデコードし、メモリ内で置き換え、同じエンコーディングで再書き込みします。この疑いがあるファイルには、標準の Edit/Write ツールを決して使用しないでください。
編集のたびに確認し、編集前だけでなく確認してください。リポジトリにgitがある場合、編集直後に git diff --stat を実行します。削除数が意図した変更よりもはるかに多い場合は、予想される編集ではなく、破損の兆候です。gitがない場合は、編集前後のファイルサイズを比較します。
うっかり破損してしまった場合: 正しい方法で再試行する前に、git checkout -- archivo で元に戻します（元のバイトをそのまま復元します）。失われたアクセントは、上書きされた後は回復できません。
Claudeが作成する（編集しない）新しいファイルの場合: プロジェクトが要求する場合（該当するかどうかをユーザーに確認）、明示的にBOM付きUTF-8にします。

6. 全般的な姿勢 — シニアとして行動し、決して当然のことと思わない

「このように動作するはずだ」、パターンが他の場所と同じように繰り返される、またはメモリや表面的な読み取りが示唆するデータ/スキーマが正しいと想定しないでください。常に実際のプロセスを検証します:

スキーマ、データ、または動作を主張する前に、実際のデータベース（DEV）に対して検証します。想定せず、確認します。
画面/SPが何をするかを主張する前に、実際のコード（grep/ファイルを読む）に対して検証します。名前や最初の読み取りを信頼しないでください。
「必要そうに見える」ものを追加する前に、HU/要件ドキュメントに対して検証します。明示されていない場合は、惰性で構築しないでください。
各変更の結果（SET PARSEONLY ON、git diff、テスト実行）を、完了したとみなす前に検証します。ロジックが正しく見えるからといって、コンパイル/実行が成功したと想定しないでください。

7. データベースに対する実行ルール（スクリプトのDDLだけでなく、すべてに適用されます）

データベースに対してINSERT/UPDATE/DELETE/DDLを決して実行しないでください。DEVであっても、チャットでの明示的な確認があっても実行しないでください。データベースに書き込むものはすべてユーザー自身が実行します。Claudeの役割はスクリプトを準備し、ユーザーがそれを実行した後、SELECTで期待通りになっていることを検証することです。これは ORG/MOD フォルダのルールとは独立しています。カタログ、テストデータ、あらゆる書き込みにも適用されます。
読み取り専用クエリ（SELECT、INFORMATION_SCHEMA、sys.sql_modules）は、毎回許可を求めることなく自由に実行できます。
データベースサーバー、データベース名、ユーザー、パスワードはどのファイルにも文書化しません（README.md、Compartidos\、.sql スクリプト、コードコメント）。特定のデータベース名はポータル/プロジェクトによって異なるため、書き留める価値のある固定値はありません。ユーザーは必要なときにチャットでパスワードとともにこれらを提供し、そのセッションのコマンドでのみ環境変数として使用されます。次回も再度要求し、「もう尋ねなくて済むように」保存しないでください。すでにパスワード/接続がある場合は…

8. gitコミット — 著作者とポリシー

Claudeが関与するあらゆるリポジトリ（初期化、ファイルのステージング、コミット）において、git config user.name と git config user.email は決して変更しないでください。 マシン上にすでに設定されているグローバル値はそのままにしておきます。著者情報をClaudeのものに変更しないでください。
コミットは明確で説明的なメッセージで行い、変更の内容と理由を簡潔に説明します。
コミットする前に常に git diff を実行して、ステージングされている内容を確認し、予期しない変更や破損がないことを確認します。

9. 中断/停止 — 進行中のコンテキストの損失を防ぐ

何らかの理由（チャットのリセット、エラー、ユーザーによる明示的な停止）で構築を中断する必要がある場合は、内部状態を README.md に書き込みます。特に:

保留中のステップを「保留中の開発」セクションの下の箇条書きで一覧表示します。
決定されたがまだ実装されていないアーキテクチャ上の決定事項を文書化します。
解決されていない質問を「お客様への質問」セクションに追加します。これにより、再開時に（同じClaudeプロジェクト内であっても）前回のセッションのメモリを失った場合でも、READMEを読むだけで続行できます。

10. 新しい個別の要件 — 「関連要件」のメカニズム

コンテナフォルダ内の別のサブフォルダにある別の要件は、次の場合に「関連」していると見なされます:

データベースオブジェクト（テーブル、SP、ビュー）を共有している。
画面またはプロセスを共有している。
データの依存関係がある（一方の出力が他方の入力である）。

実装要件（フォルダ構造 + ログ）