mp-review

mp-review

このスキルは、Mercado Pago のインテグレーションを監査します。セキュリティの最低基準はローカルで評価します。公式の品質基準は、MCP を使用するスコープがそのステップに到達した場合にのみ、ライブで取得します。

---

Step 0 — MCP を使用するレビュー手順でのみ接続する

レビュー開始時に MCP の状態を調べないでください。まずインテグレーションを特定し、要求されたローカルチェックをすべて実行してください。

レビュー操作	MCP が必要か	ツール
セキュリティの最低基準（scope=security）	いいえ	—
コードの検出とレガシーの検出	いいえ	—
公式品質チェックリスト	はい	quality_checklist
決済レベルの品質評価	はい	quality_evaluation
ホモロゲーションフォームの取得または送信	はい	form_homologation

MCP を使用する操作の直前に、次の手順を実行してください。

1. 呼び出し可能であれば、使用するツールを直接呼び出してください。接続テストだけを目的に application_list を呼び出してはいけません。
2. ツールを利用できない場合、または認証エラーが返された場合は、mcp__plugin_mercadopago_mcp__authenticate を呼び出し、OAuth リンクを開発者の使用言語で表示してください。
3. 開発者に、URL を外部ブラウザーにコピーせず、Mac では Cmd+Click、Windows/Linux では Ctrl+Click するよう案内してください。
4. 開発者が戻ってきたら、使用するツールを直接再試行してください。コールバック URL を尋ねてはいけません。
5. 認証に 2 回失敗した後は、完了済みのローカルチェックを続行し、MCP を使用するセクションを未検証として記載してください。

---

Step 1 — インテグレーションを特定する

Grep/Glob を使って、次の項目を検索してください。

• mercadopago（任意の SDK）をインポートするファイル。
• MP_ACCESS_TOKEN またはハードコードされた APP_USR- / TEST- 文字列への参照。
• エンドポイントのパターン：/v1/payments、/checkout/preferences、/v1/orders、payment.create、preference.create、order.create、preapproval.create、disbursement。
• Webhook ハンドラー（webhook、notification、ipn に一致するパス）。

以下を特定してください。

• 使用中の API：Payments API（/v1/payments）と Orders API（/v1/orders）。両方が共存する場合もあります。
  • インテグレーションがレガシー Instore API を使用している場合は、レガシーな方式です。Implementation Report に、ファイルと行番号を記載した Needs attention 項目を必ず追加し、移行コマンドを提案してください："Run /mp-integrate migrate to automate the migration to the Orders API." Blocker として扱ってはいけません（既存のコードは引き続き動作します）が、将来に向けた技術的負債として指摘してください。フラグを付けるレガシー Instore パターン：
    • /mpmobile/instore/qr（QR Instore）
    • /instore/qr/seller/collectors（QR Instore V2）
    • /instore/orders/qr/seller/collectors（QR Dinámico）
    • /point/integration-api/devices/{id}/payment-intents（Point）
  • インテグレーションが /v1/payments を使用している場合（オンライン）、サーバー側でのカード決済（Checkout API / Marketplace）であれば技術的負債としてフラグを付けてください。オンラインの場合、これらの製品の移行はこのプラグインの対象外であるため、/mp-integrate migrate を提案してはいけません。
  • 例外 1：Checkout Pro は preferences を引き続き使用します（Checkout Pro には Orders API がありません）。/checkout/preferences にレガシーのフラグを付けないでください。
  • 例外 2：Bricks は /v1/payments を正しく使用します（CardPayment によるトークン化の後、サーバー側で使用）。CardPayment または onSubmit を含むファイル内の /v1/payments 呼び出しには、レガシーのフラグを付けないでください。
• 使用中の製品：Checkout Pro/API、Bricks、Subscriptions、Marketplace など。エンドポイントのパターンとリクエストペイロードから特定してください。

---

ステップ 2 — 公式品質チェックリストを実行する

scope=security の場合は、このステップをスキップします。公式の品質基準を含むその他のスコープでは、次の呼び出しの直前にステップ 0 を適用してください。

mcp__plugin_mercadopago_mcp__quality_checklist を呼び出します。レスポンスには次の内容が定義されています。

• 必須フィールド — Mercado Pago の品質基準を満たすために実装が必要です。
• ベストプラクティス — 推奨される改善点です。

返されたすべての項目について（要約したり、省略したりしないでください）：

1. Grep／Read でコードベースを検索し、項目の根拠（フィールド、ヘッダー、動作）を確認します。
2. 各項目を実装済み、未実装、または一部実装と判定し、その根拠となるファイル／行を示す簡潔な理由を添えます。

---

ステップ 3 — 横断的なセキュリティチェックリスト

これらの項目は quality_checklist に常に含まれるとは限りませんが、本番環境のすべてのインテグレーションで必須です。必ず評価してください。

#	チェック項目	確認方法
1	process.env または同等の仕組みでアクセストークンを管理し、ハードコードしない	.env* とテスト用フィクスチャ以外の場所で APP_USR-／TEST- を Grep で検索します
2	.env が .gitignore に含まれ、.env.example は含まれていない	.gitignore を読みます
3	Webhook ハンドラーが x-signature（HMAC-SHA256）を検証する	mp-webhooks スキルを参照し、x-signature、x-request-id、createHmac を Grep で検索します
4	back_url と notification_url に HTTPS を強制する	URL の構築箇所で http:// を Grep で検索します
5	リダイレクト後にサーバー側で支払いステータスを検証する	back_url の後に /v1/payments/{id} または /v1/orders/{id} をサーバー側で取得している箇所を探します
6	支払い／注文の作成時に冪等性キーを送信する	X-Idempotency-Key または SDK の同等の機能を Grep で検索します
7	すべての設定／注文で external_reference を設定する	external_reference を Grep で検索します
8	テストユーザーの認証情報を本番デプロイに含めない	テスト用認証情報が別の環境ファイルまたはボルトから読み込まれていることを確認します
9	sandbox_init_point をどこにも使用しない	sandbox_init_point を Grep で検索します。一致するものはすべてバグとして報告してください。Mercado Pago にはサンドボックスがなく、この URL はすべての環境で無効です

---

ステップ 4 — quality_evaluation を実行する（対応している場合）

mcp__plugin_mercadopago_mcp__quality_evaluation の実行には実際の payment_id が必要です。インテグレーションが Payments API を使用し、支払い ID が生成されている場合に実行します。

開発者から ID が提供された後に限り、この呼び出しの直前にステップ 0 を適用してください。

インテグレーションの使用 API	対応
Payments API（/v1/payments）	開発者に最近のテスト用 payment_id を尋ね、それを使って mcp__plugin_mercadopago_mcp__quality_evaluation を呼び出します。
Orders API のみ	非対応のためスキップします。レポートに記載してください。

mcp__plugin_mercadopago_mcp__quality_evaluation(
  payment_id="<recent_test_payment_id>"
)

開発者が payment ID を持っていない場合はスキップし、レポートに "quality_evaluation: skipped — no payment_id provided." と記載してください。

---

ステップ 4.5 — 認定フォーム（本番環境に移行する前の最終ステップ）

quality_evaluation の実行後（またはスキップした場合）は、開発者に認定フォームの利用を案内します。

「本番用の認証情報に切り替える前に、公式認定チェックリストを完了してください。これによりインテグレーションが認定され、本番環境で有効になります。」

1. 開発者が案内を受け入れた場合は、mcp__plugin_mercadopago_mcp__form_homologation を action="get_form"、検出された製品の product_id、検出された国の site_id、lang、is_ca（Checkout API／Bricks の場合は true）とともに呼び出す直前に、ステップ 0 を適用してください。
2. AskUserQuestion を使って各ステップ／質問を開発者に提示し、回答を収集します。
3. すべての質問への回答がそろったら、収集した form_values と action="submit" を指定して呼び出します。
4. 成功した場合は、開発者に祝意を伝え、インテグレーションが認定されたことを確認します。

開発者がスキップした場合は、Implementation Report の「Needs attention」に "Homologation form not submitted — required before production deployment." と記載してください。

ステップ 5 — 実装レポートを出力する（必須の最終ステップ）

ステップ 1〜4 が完了したら、必ず出力の最後に実装レポートを出力してください。これは開発者が引き継ぐ成果物であり、完了した作業、保留中の作業、次に行うべきことをまとめたものです。省略したり、文章で要約したりせず、以下の構造化されたブロックをそのまま出力してください。

レポートは、開発者の次のセッションにおける信頼できる情報源です。何を確認し、何を指摘し、次に具体的に何をすべきかを正確に伝えます。レポートがないと、レビューが中途半端に感じられ、開発者はリリースしてよいか判断できません。

---

出力形式

## Mercado Pago Integration Review

**Scope**: {full | security | webhooks | checkout | qr | subscriptions | marketplace | quality}
**API detected**: {Payments API | Orders API | both}
**Products detected**: {list}
**Files analyzed**: {list}

### CRITICAL
- {issues that block production or expose credentials}

### WARNINGS
- {issues that may cause incidents but do not block release}

### PASS
- {items correctly implemented}

### Quality Standards

{If `quality_checklist` ran: render every official item below. If it was not requested, write `Not requested for this scope.` If authentication failed, write `Not verified — MCP connection was unavailable.` Do not fabricate rows or scores.}

#### Required fields
| # | Field | Description | Status | Evidence |
|---|-------|-------------|--------|----------|
| 1 | … | … | Implemented / Missing / Partial | path:line |

#### Best practices
| # | Practice | Description | Status | Evidence |
|---|----------|-------------|--------|----------|
| 1 | … | … | Implemented / Missing / Partial | path:line |

### Security checklist (cross-cutting)
| # | Check | Status | Evidence |
|---|-------|--------|----------|

### Recommendations
- {actionable, ordered by impact}

**Summary**: {X/Y required fields implemented and Z/W best practices adopted, if verified; otherwise `Official quality: not requested/not verified`}. {S}/9 security checks pass.

{Offer `quality_evaluation` only for a compatible Payments API review where the developer requested MCP-backed quality analysis.}

---

## Implementation Report

### Verified
- [x] {item that passed — e.g., "Webhook handler validates x-signature with HMAC-SHA256"}
- [x] {next passing item}

### Needs attention
- [ ] {actionable item with file:line — e.g., "Add idempotency key to POST /v1/orders at api/orders.js:42"}
- [ ] {next pending item}
- [ ] {if legacy `/v1/payments` is detected — e.g., "Migrate POST /v1/payments to the Orders API (POST /v1/orders) at api/payments.js:42. The Payments API is being deprecated."}

### Blockers (must fix before production)
- [ ] {critical item — e.g., "Hardcoded APP_USR- token in config/mp.js:8 — move to env"}

### Next steps
1. {The single most impactful action the developer should take next}
2. {Follow-up actions in priority order}
3. Re-run `/mp-review` after fixes to confirm the report.

### Resources used
- Local: codebase inspection + cross-cutting security floor
- MCP: `quality_checklist` (include only if called, with date/time)
- MCP: `quality_evaluation` (include only if called, with the payment_id used)
- MCP: `form_homologation` (include only if called)
- Skill: `mp-review` v4.3.2

**Scores**: {X/Y required and Z/W best practices if verified; otherwise `official quality: N/A`}, {S}/9 security. **Verdict**: {Ready for production | Needs fixes | Blocked | Partial — MCP checks not verified}.

---

このスキルで行わないこと

• コードの生成やひな形の作成は行いません。mp-integrate を使用してください。
• 状態を変更する API は呼び出しません。quality_evaluation は読み取り専用であり、提案されるのみです。
• オフラインで公式の品質基準を捏造しません。固定のセキュリティ基準はローカルにあり、公式の基準は、MCP が対応するスコープが要求された場合にのみ取得されます。