fcode-code-validation

Factorial Code — アプリの検証

プラットフォーム自体のリリース検証に向けた事前チェックです（基準は fcode-ama references/journey.md §8 に記載されています）。リリースを 申請する前にローカルで実行し、人間のゲートキーパーが確認するレビュー項目である、 フォームとライフサイクル、i18n、ログの衛生状態、セキュリティ、メールの不正利用を 追加します。

同じ手順で、2 種類の利用者に対応します。リリースを申請する前に セルフチェックするアプリ開発者と、リリースを審査するプラットフォームの レビュアーです。いずれの場合も、入力はワークスペース（「team」）のスラッグで、 出力はクローンしたワークスペース内の APP_VALIDATION_REPORT.md と、 チャットでの ✅/❌ 判定です。

このスキルが管理するのは、手順、チェック項目、重大度、レポート形式のみです。 チェック対象の各 ルール は別のスキルが管理しており、カタログの各行に そのスキルを記載しています。指摘事項の背景を確認する必要がある場合は、 管理元のスキルを参照してください。

注意点

• このレビューは読み取り専用です。 書き込みが許可されるのは、クローンそのものと APP_VALIDATION_REPORT.md のみです。fcode push、--force、 settings:versions:create / settings:aliases:set は絶対に実行せず、 ワークスペースのファイルも編集せず、レポートに対して fcode add も実行しないでください。
• レビュー中に fcode run を実行してはいけません。 プロセスが親ワークスペースから 引き継いだ認証情報を使って実際の API を呼び出す可能性があります （fcode-core-concepts）。これはコードと設定を対象とする 静的な レビューです。
• クローンのスラッグは、アプリの UUID ではなく、エンコードされた dev-… トークンです。 アプリの Development タブにある「How to build locally」ガイドからコピーしてください （fcode-cli を参照）。UUID 形式のスラッグではクローンできません。
• Blocker が1件でもあれば → ❌ です。 Warning と Suggestion では判定は変わりません。
• 曖昧さがある場合はレビューを中断します。 ユーザーが複数のアプリを持つ development team を指定した場合や、どのワークスペース（dev- / deploy- / prod-）をレビューすればよいか不明な場合は、候補を列挙してクローンする前に 確認してください。通常のレビュー対象は dev- です。
• 取得した変数にある ******** のプレースホルダーは正常です。 マスクされた シークレットは指摘事項ではなく、レビューで実際のシークレット値が必要になることも ありません。シークレット値を尋ねてはいけません。
• fcode clone の失敗は、通常、UUID の取り違えかアクセス権の不足が原因です。 むやみに再試行せず、fcode-ama のアクセス手順を案内してください。
• JavaScript と Python が混在するワークスペースでも問題ありません。 各プロセスを それぞれの言語のルールでレビューし、レポートのヘッダーに混在していることを記載してください。
• ワークスペースが所有する内容だけをレビューしてください。 parentTeams の親から 継承したリソース（モジュール、プロセス、変数）、variables.inherited.env、 i18n/<locale>.inherited.yaml は、所有元のワークスペースが公開された際にすでに 検証されています。その内容は監査しないでください。指摘事項の対象にしてよいのは、 この ワークスペースでの利用方法のみです。

重大度モデル

重大度	意味	判定への影響
Blocker	実行時に問題を起こす、認証情報を不適切に扱う、プラットフォームのメールドメインを不正利用にさらす、またはプラットフォームのリリースゲートが確認する基準を満たさない	1件でもあれば → ❌
Warning	文書化されたルールに違反している。レビュアーからの指摘や将来的な問題が予想される	参考情報
Suggestion	プラットフォームの規約に沿った改善案	参考情報

手順

1. ワークスペースを特定します。 スラッグがエンコードされたトークンであること（「注意点」を参照）と、ワークスペースの種類を確認します。必要に応じて、ユーザーに確認して判別します。レポートのヘッダーに種類を記録します。
2. 取得します。 CLI がない場合はユーザーに確認してから、pnpm install -g @factorialco/fcode-cli を実行します。許可されているインストールはこれだけです。新規コピーの場合は、fcode clone <workspace-slug> --skipSkillsSetup を実行します。すでにクローン済みの場合は、fcode pull を実行します。差分がある場合は、決して --force を使わず、ローカルの状態をそのまま確認するかユーザーに尋ね、その回答をレポートのヘッダーに記録します。
3. インベントリを作成します（読み取り専用）。各プロセスの言語を判定します（index.js と main.py）。各 processes/<slug>/metadata.json から、プロセス、モジュール、appRole、Webhook／フォームの設定を一覧にします。settings.json、3つの変数ファイル、variables.meta.json、および i18n/ を読み込みます。fcode status、fcode variables:status、fcode settings:status、fcode i18n:status を実行します。作業を進めながら、所有リソースと継承リソースを区別します。カタログの対象は所有リソースのみです（「注意点」を参照）。
4. チェックカタログを実行します。 references/checks.md を読み込み、インベントリに基づいてすべてのチェックを評価し、file:line 形式で根拠を記録します。手順2で新規クローンを行ったか、既存のローカルワークスペースを使用したかに応じて、STRUCT レイアウトチェックをすべて実施するか、「N/A — fresh clone」として記録します。
5. 分類します。 カタログの各項目に指定された重大度を適用します。項目で許可されている場合に限り変更し、指摘事項にその理由を記載します。
6. レポートを作成します。 references/report-template.md に従って、<workspace>/APP_VALIDATION_REPORT.md にレポートを作成し、前回の実行結果があれば上書きします。
7. チャットに判定結果を出力します。 ✅／❌ の行、重大度ごとの件数、Blocker のタイトルを出力します。

チェックカテゴリ

STRUCT · LANG · FORM · I18N · SEC · MAIL · REUSE · LOG · LIFE · REL — チェックごとの重大度と所有者の出典を含む完全なカタログは、references/checks.md にあります。