specsfy-04-validate

仕様を検証する

必須の準備

このスキルを実行する前に、プロジェクトのルートで $specsfy-setup を必ず読み込んでください。自動ハンドオフの場合は、このステップの前に再度読み込んでください。 会話で確認済みのルートを再利用し、セットアップで未解決の項目が示された場合は先に進まないでください。

対話モード

対話モード：perguntas。 質問を作成する前に、.specsfy/Spec.md の Contrato de perguntas numeradas を読み、適用してください。

spec.md を唯一の信頼できる情報源として、自然言語で記述されたコードとして扱ってください。まず厳格な形式を確認し、その後、意味の面から明瞭さ、完全性、一貫性、テスト可能性を検証してください。

会話を調整する

このステップが完了したとき、または別のステップの作業を検出したときは、 Pendência detectada: <descrição> — ação: resolvendo nesta etapa と通知し、それがこのステップの範囲内であれば解決してください。責任の移行が発生する場合は、 Transição automática: $specsfy-04-validate → $<destino> — motivo: <motivo> — resultado esperado: <resultado> と通知し、確認を求めたりコマンドを繰り返したりせず、直ちに移行先のスキルを読み込んでください。同じ会話の中で続行してください。このステップで必要な修正を行った後は、 Retomada automática: $<destino> → $specsfy-04-validate — pendência resolvida: <resultado> と通知し、直ちにこのステップに戻ってください。ハンドオフのたびに状態を再評価し、循環を避けてください。ハンドオフの確認は求めないでください。機密性の高い操作には、引き続き個別の許可が必要です。

検証を実行する

1. 指定されたパスから specs/<estado>/<NNNN>-<slug>/spec.md を特定します。複数の仕様があり、slug が指定されていない場合は、どれを検証するか尋ねてください。
2. Formato: Specsfy/2.0、3つの行為の順序、ディレクトリ名と一致する slug、パッケージが spec.md と任意の research/ ディレクトリに限定されていることを確認します。
3. 参照したすべての外部 API またはドキュメントについて、research/ にローカルの根拠があり、その索引が Artefatos de pesquisa armazenados に記載されていることを確認します。これらの資料は参考情報であり、第二の規範的な情報源ではありません。
4. Status または Definition Gate が未完了である間は、次を実行します。

node .agents/skills/specsfy-04-validate/scripts/validate_spec.mjs specs/<estado>/<NNNN>-<slug>/spec.md --allow-draft

1. references/quality-gates.md を読み、意味面のレビューを実施します。
2. Interface para pessoas フィールドを確認します。値が Sim の場合、セクション 10 に、確認済みのスタックと規約、画面と責務、情報の流れとナビゲーション、メニューと主要ナビゲーション、フォームと操作、構成と配置、状態とアクセシビリティが記載されていることを必須とします。提案されたテクノロジーがスタックの情報源に従っているか、または未解決の点が担当者向けに記録されているかを確認します。画面とフォームのない CRUD は BLOCKER です。未解決の点を明確にするため、自動的に $specsfy-02-backlog に戻ってください。
3. research、要件、BDD、技術計画、データモデル、契約、TDD、マトリクス、タスクを比較します。feature 全体、および各 US、FR、NFR に対して、異なる AC が最低3つあることを確認してください。「ファイルの形式が整っている」ことと「仕様が正しい」ことを混同しないでください。
4. プロダクト、アーキテクチャ、またはセキュリティが重要な場合は、references/review-lenses.md を読み、セクション 13 に findings を記録して、scripts/review_findings.mjs を実行します。P1 Open がある場合、ゲートは未完了のままです。
5. 定義によってスタックまたは永続化が変更される場合、Definition of Done でそれぞれ .specsfy/STACK.md または .specsfy/DATABASE.md を参照することを必須とします。目的または能力に重要な変更がある場合は PROJECT.md のレビューを必須とします。確認済みの新しいルールがある場合は .specsfy/RULES.md を必須とします。
6. 最終承認時に、[MIGRATION] タスクを探し、該当する各タスクについて verify_evidence.mjs --delivery を実行します。タスクが未完了の場合、またはファイル、適用コマンド、状態照会のいずれかが存在しない場合は、Delivery Gate を未完了のままにします。

指摘事項の分類

• BLOCKER：正しいタスクまたはテストの実行を妨げます。矛盾する要件、観測可能な動作の欠如、影響の大きい判断の欠落、または主要シナリオの未対応が該当します。
• WARNING：手戻りやリスクを増やしますが、安全に実装できます。
• NOTE：実質的な影響のない編集上の改善です。

指摘ごとに、セクションまたは ID を示し、影響を説明して、具体的な修正案を提示してください。

ゲート

結果は次のいずれか一つだけを返してください。

• READY：フォーマットの不備がなく、未解決の BLOCKER がありません。
• NOT READY：構造上の不備、または BLOCKER があります。

件数、最低限のカバレッジ US/FR/NFR ↔ 3 ACs、重要度の高い指摘 3 件、および次の自動遷移を含めてください。

• READY → $specsfy-05-tasks でセクション 14 を計画します。
• NOT READY → 判断が不足している場合は $specsfy-02-backlog に戻します。バックログの洗練ではサイクル全体を実行し、この検証は不足点を解消するか明示的な出力 avançar を記録した後にのみ再開します。その出力の後は NOT READY を記録し、この再開中に同じサイクルを再度開始しないでください。修正方針がすでに決まっている場合、以前に承認された spec には $specsfy-update-spec を、初期定義には $specsfy-03-specify を使用します。

理由を告知し、選択した skill を直ちに読み込んでください。

単一ファイルへの記録

要件を自動的に変更せず、次の手順を実行してください。

1. セクション 13 の Gate do Ato I — Definição を更新し、結果、日付、指摘事項を記録します。
2. READY の場合は Definition Gate: Passed と Status: Defined を設定します。
3. NOT READY の場合は Definition Gate: Failed、Plan Gate: Pending、Delivery Gate: Pending を設定し、Status: Draft を維持します。
4. ゲートが通過したら、--allow-draft を指定せずに validate_spec.mjs specs/<estado>/<NNNN>-<slug>/spec.md を再実行します。
5. 結果をチャットで報告します。

Definition Gate が通過したら、specsfy transition <id> defined を実行してください。 review では、最終承認にも同じ分析を使用します。Delivery Gate が通過し、Status が Complete で、DoD が立証されたら、specsfy transition <id> completed を実行してください。 それ以前に、回答によって納品物または Effort が変わる可能性がある場合は、$specsfy-interviewer を呼び出してください。

ユーザーが修正を求めた場合は、元のセクションを編集し、ID を保持して再検証してください。別の仕様ファイルや検証ファイルを作成してはいけません。

リポジトリの Enforcement

ローカルと CI で同じ runner を使用します。

node .agents/skills/specsfy-04-validate/scripts/verify_repo.mjs . \
  --boundary local --timeout-seconds 300 --max-output-bytes 65536

local、git、ci の境界によってポリシーは変わりません。アテステーションを永続化する唯一の方法は --attestation PATH です。--self-test は一時ディレクトリ内でカナリーを実行し、証明用のバインディングを生成することはありません。schema 2 のアテステーションは、commit、実行可能ファイルの digest、合格したチェック、タスク、ファイルハッシュを関連付けます。digest はコマンド、上限、ポリシーのファイルを対象とします。一つの境界でしか通過しないゲート、上限超過、または truncated と記録されずに診断が切り詰められたゲートは受け入れないでください。

カタログの契約では、基本 skills 14 個、specsfy-setup、specsfy-documentator、および specsfy-aux-* 3 個を必須とします。また、インストール済みの各 specsfy-specialist-* を検証しますが、specialist の合計数に上限は設けません。 Gherkin BDD は spec.md のみを参照元とし、enforcement が .feature を実行することはありません。PHP プロジェクト（PHP + Node を含む）では、派生テストを Pest で実行します。PHP を使用しない Node プロジェクトでは、test:tdd スクリプトが必須です。存在しない場合は失敗し、skill にユーザーへの質問と Vitest の提案を促します。

必要に応じた専門家

ゲートで特定の技術レビューが必要な場合は、references/specialists.md を読んでください。インストールは明示的な推奨であり、検証の副作用ではありません。