contextualizar-negocio

ビジネスのコンテキスト化（ブラウンフィールド）

目標

システムが現在何をしているのか、どのようなルールに従うのか、それぞれのものを何と呼ぶのかを、ビジネス用語と根拠を用いて説明します。ブラウンフィールドには PRD もバックログもありません。システムの動作はコードに記されており、そのルールの多くはほかの場所には書かれていません。

このスキルでは機能コンテキスト（レイヤー 3 と 4）を扱います。技術コンテキストは ARCH が contextualizar-repo を使って作成します。

**このスキルはコードを変更せず、新しい機能も提案しません。**情報を収集し、文書化し、質問をして、そこで停止します。

原則

1. **ビジネス用語を使う。**各機能と各ルールは、PO が理解できるように記述します。技術的な根拠は説明の代わりではなく、説明に添えます。
2. **根拠のない記述はしない。**各機能と各ルールには、その根拠（エンドポイント、画面、テスト、または ファイル:行）を記載します。根拠がない場合は NO VERIFICADO とします。
3. **コードの動作が、必ずしもビジネスの意図とは限りません。**ルールが誤りのように見える場合や曖昧な場合、修正も解釈もせず、ビジネスへの質問にします。

入力

• ARCH の docs/contexto/ARQUITECTURA.md（または通知 CONTEXTO TÉCNICO LISTO）：確認すべき場所を示します。存在しない場合は、ARCH が先に実行するかを確認します。人間が確認した場合に限り、それなしで続行し、その場合は調査に時間がかかり、精度も低くなることを伝えます。
• 既存のユーザー向けドキュメント（ある場合）。
• 任意：画面を確認するための、実行中のアプリケーション。

ワークフロー

1. 情報源

システムの動作を記述する情報源を、次の順序で確認します。

1. **公開インターフェース：**API エンドポイント、画面、コマンド。
2. **既存のテスト：**具体例を用いて、期待される動作を記述しています。
3. **設定：**ユーザー向けの動作を変えるオプションやフラグ。
4. ユーザー向けドキュメント。
5. **コード：**動作を確認し、前の情報源に現れない内容を見つけるために確認します。

2. 機能マップ（レイヤー 3）

ファイルやエンドポイントではなく、ビジネス機能ごとに分類します。機能ごとに、次の項目を記載します。

• 何ができるのかを、ビジネス上の表現で一文にまとめる。
• 誰が使うのか（アクター）。
• 根拠（エンドポイント、画面、テスト、または ファイル:行）。
• 状態：有効 · 設定オプションで制御 · 非推奨。

assets/capacidades-template.md を使用します。

3. 隠れたビジネスルール（レイヤー 3）

ユーザーができることに影響する検証、制限、変換、権限、デフォルト値をコードから探します。ルールごとに、次の項目を記載します。

• ビジネス用語での記述（「文書は 100,000 文字を超える状態では作成できない」など）。
• 根拠 ファイル:行。
• ほかの場所に記載されているか（はい／いいえ）。
• 曖昧な場合、または誤りのように見える場合：ビジネスへの質問とし、解決しません。

4. 用語集（レイヤー 4）

assets/glosario-template.md を使って docs/contexto/GLOSARIO.md を作成します。

1. インターフェース、API、コードに登場するドメイン用語を集めます。
2. 用語ごとに、ビジネス上の定義、同義語、コード上の名称（異なる場合）、識別子がある場合はその形式を記載します。
3. **「Dónde vive」**列は ARCH が記入します。次のメッセージを送ります。 GLOSARIO: TÉRMINOS NUEVOS: <ruta> — <cantidad de términos> セッションに ARCH がいない場合は、根拠を記載し、pendiente de revisión técnica とします。
4. 同じ用語が場所によって異なる意味を持つ場合は、定義を選ばず、矛盾として記録します。

5. 作成

ファイル	内容
docs/contexto/CAPACIDADES.md	機能マップ + ビジネスルール + ビジネスへの質問
docs/contexto/GLOSARIO.md	ビジネス用語 ↔ コードの用語集

AGENTS.md がすでにこれらのファイルを参照している場合（ARCH が設定済みの場合）は、変更しません。そうでなければ、リンクの追加を提案します。

6. 自己検証

• 引用した各エビデンスを再度開き、記載内容の根拠になっていることを確認します。
• いかなる機能やルールも、新規のものや提案中のものとして記述されていないことを確認します。
• 用語集の各用語にビジネス上の定義があることを確認します。

7. 人間による承認ゲート

要約とビジネス向けの質問を、できれば PO に提示します。機能的コンテキストを確定する前に、明示的な承認を待ちます。

ARCH との連携

• 開始前に CONTEXTO TÉCNICO LISTO を待ちます（人間が別途指示した場合を除きます）。
• コード内に該当箇所がない用語がある場合は、GLOSARIO: TÉRMINOS NUEVOS を送信します。
• GLOSARIO COMPLETO を受け取ったら、各該当箇所がビジネス上の定義と一致しているか確認し、一致しない場合は具体的な相違点を伝えます。
• 同じ不一致に関するやり取りは最大 2 回までとし、その後は人間が判断します。

制約

• ARCH のコードや技術文書は変更しません。
• 新機能は提案せず、既存の機能を文書化します。
• 曖昧なルールは解決せず、質問します。
• 人間の承認なしに機能的コンテキストを確定しません。