qfai 1.0.3 → 1.0.5

package/assets/init/.qfai/prompts/qfai-classify-change.md

@@ -1,33 +0,0 @@
-# QFAI: Compatibility / Change 分類（変更区分の判断支援）
-
-あなたは差分を分析し、変更が Compatibility か Change かを分類します。
-
-## 目的
-
-- delta.md の変更区分を明確にし、レビューポイントを固定する
-- 影響範囲（Spec/Scenario/Test/Contract）を明示する
-
-## 必須入力
-
-- `.qfai/specs/**/delta.md`
-- 変更差分（`git diff`）
-- 参照元の Spec/Scenario/Contracts（必要に応じて）
-
-## 手順
-
-1. 差分を読み、ユーザー影響（互換維持/破壊）を分類する。
-2. 影響範囲（Spec/Scenario/Test/Contract）を列挙する。
-3. 変更区分の根拠を簡潔にまとめる。
-4. 必要なドキュメント更新（README/CHANGELOG/Spec）を列挙する。
-
-## 禁止事項
-
-- 仕様を勝手に変更しない
-- delta.md の内容を無断で上書きしない
-- 変更理由の捏造をしない
-
-## 出力フォーマット
-
-- 分類（Compatibility / Change）と根拠
-- 影響範囲（ファイル/機能/テスト）
-- 追記すべきドキュメントのチェックリスト

package/assets/init/.qfai/prompts/qfai-generate-test-globs.md

@@ -1,29 +0,0 @@
-# QFAI: テストファイル glob 生成（プロジェクト分析→qfai.config.yaml 更新）
-
-あなたはリポジトリを解析し、QFAI の SC→Test 判定に使用する「テストファイル glob」を作成します。
-
-## 目的
-
-- SC→Test の根拠は **テストファイル内の `QFAI:SC-xxxx`** アノテーションです。
-- その抽出対象（テストファイル集合）を、プロジェクト実態に合わせて **過不足なく**指定してください。
-
-## 手順
-
-1. どのテストフレームワーク/ランナーが使われているかを特定してください。
-   - 例: `package.json` の dependencies/devDependencies、設定ファイル（`vitest.config.*`, `jest.config.*`, `playwright.config.*` 等）、CI 設定など
-2. テストファイルが存在するディレクトリと命名規則を列挙してください。
-   - `tests/` 配下だけでなく、**`src/` 同居**（`*.test.*`）も考慮すること
-   - e2e / integration / unit が分かれている場合はそれも考慮すること
-3. 「テストファイル glob（含める）」を 3-10 個程度で提案してください。
-   - 過剰に広い `**/*` は禁止（性能・誤検知の観点）
-4. 「除外 glob」を提案してください（既定除外に加えて必要なら）。
-5. `qfai.config.yaml` を更新してください。
-   - `validation.traceability.testFileGlobs` に glob 配列を設定
-   - 必要なら `validation.traceability.testFileExcludeGlobs` も設定
-6. 更新後、実在するテストファイルを 5-15 件サンプリングし、各ファイルが提案 glob にマッチすることを示してください。
-7. 最後に、提案 glob を 1 行ずつコメント付きでまとめてください（採用理由を短く）。
-
-## 制約
-
-- `.qfai/` 配下、`node_modules/`、ビルド成果物（`dist/`, `build/` 等）は対象外
-- 変更は **glob 設定に限定**（テストやソースの内容改変はしない）

package/assets/init/.qfai/prompts/qfai-maintain-contracts.md

@@ -1,35 +0,0 @@
-# QFAI: 契約保守（Contract ID と Spec 参照の整合）
-
-あなたは契約ファイルの追加/変更に合わせて、ID と参照の整合を保ちます。
-
-## 目的
-
-- `QFAI-CONTRACT-ID` と `QFAI-CONTRACT-REF` の整合を保つ
-- orphan contract を発生させずに運用できるようにする
-
-## 必須入力
-
-- `.qfai/contracts/**`（追加/変更した契約）
-- 関連する `spec.md`（候補は report の Spec→契約一覧）
-- `.qfai/out/report.md` / `.qfai/out/validate.json`（あれば）
-
-## 手順
-
-1. 追加/変更した契約の種別（UI/API/DB）と命名規約を確認する。
-2. `QFAI-CONTRACT-ID` の採番案を作り、ファイル名と一致させる。
-3. 参照すべき Spec を特定し、`QFAI-CONTRACT-REF` へ追記案を作る。
-4. orphan contract が出る場合は、Spec 追加/更新の方針を提示する。
-5. 変更後の validate / report 手順を示す。
-
-## 禁止事項
-
-- 既存の Contract ID を無断で変更しない
-- ID 形式（`UI|API|DB-0001`）を崩さない
-- orphanContractsPolicy の変更を無断で行わない
-
-## 出力フォーマット
-
-- 追加/変更する Contract ID と根拠
-- 参照を追加する Spec 一覧と編集案
-- 提案 diff（またはパッチ単位）
-- 再実行コマンド（`qfai validate` / `qfai report`）

package/assets/init/.qfai/prompts/qfai-maintain-traceability.md

@@ -1,36 +0,0 @@
-# QFAI: トレーサビリティ保守（Spec/Scenario/Test の参照整合）
-
-あなたは QFAI の成果物を分析し、壊れた参照（Spec/Scenario/Test）を修復します。
-
-## 目的
-
-- Spec/Scenario/Test の ID 参照が壊れた箇所を特定し、整合させる
-- 互換維持/変更（Compatibility/Change）の区分を明確にする
-
-## 必須入力
-
-- `.qfai/specs/**/spec.md` / `scenario.feature` / `delta.md`
-- `.qfai/out/validate.json`（あれば）
-- `.qfai/out/report.md`（あれば）
-- テストコード（`validation.traceability.testFileGlobs` に一致する範囲）
-
-## 手順
-
-1. validate/report の結果から、壊れている参照（Spec/BR/SC/Contract/Test）を列挙する。
-2. Spec Pack（spec/delta/scenario）を読み、ID と参照の意図を把握する。
-3. 修正が Compatibility か Change かを判断し、根拠を整理する。
-4. 参照切れを解消する最小修正案（Spec/Scenario/Test）を作る。
-5. 変更後の validate / report 手順を示す。
-
-## 禁止事項
-
-- 仕様の勝手な拡張や要件追加をしない
-- ID 形式（`PREFIX-0001`）を崩さない
-- 参照の SSOT を変更しない（Spec→Contract は Spec の `QFAI-CONTRACT-REF` が正）
-
-## 出力フォーマット
-
-- 変更区分（Compatibility / Change）と根拠
-- 修正対象一覧（ファイル/ID/理由）
-- 提案 diff（またはパッチ単位）
-- 再実行コマンド（`qfai validate` / `qfai report` / テスト）

package/assets/init/.qfai/prompts/require-to-spec.md

@@ -1,41 +0,0 @@
-# require-to-spec
-
-あなたは仕様書作成アシスタントです。`.qfai/require/` 配下の既存要件を読み取り、QFAI の Spec Pack を作成してください。
-
-## Inputs
-
-- `.qfai/require/` 配下の要件定義書・リンク・原本（読み取れる範囲で）
-- 追加資料がある場合は、それも参照して良い
-
-## Output
-
-- `.qfai/specs/spec-0001/spec.md`
-- `.qfai/specs/spec-0001/delta.md`
-- `.qfai/specs/spec-0001/scenario.feature`
-- 必要に応じて `.qfai/contracts/{ui,api,db}` 配下
-
-> Spec は `spec-0001` から開始し、必要なら連番で増やすこと。
-
-## Rules
-
-- **推測しない**。要件に書かれていないことは `TBD` と明記する。
-- ID は `PREFIX-0001` 形式（SPEC/BR/SC/UI/API/DB）。
-- `spec.md` の必須セクションは `qfai.config.yaml` の設定に従う。
-- BR は `## 業務ルール` にのみ定義し、`- [BR-0001][P1] ...` 形式で書く。
-- `spec.md` に `QFAI-CONTRACT-REF:` を必ず記載する（不要なら `none`）。
-- `scenario.feature` は Gherkin で書き、Feature に `@SPEC-xxxx` を付与する。
-- 各 Scenario は `@SC-xxxx` を **ちょうど1つ**、`@BR-xxxx` を **1つ以上**持つこと。
-- 契約ファイルには `QFAI-CONTRACT-ID: <ID>` を宣言する。
-- 契約 ID（UI/API/DB）を Scenario で参照する場合はタグまたは本文に明示する。
-- `delta.md` の「変更区分」は **Compatibility / Change/Improvement のいずれか1つにチェック**する。
-  - 判断できない場合は `Compatibility` を選び、`TBD` を理由欄に記載する。
-
-## Output Format
-
-- すべて Markdown
-- 余計な説明文は出力しない（ファイル内容のみ）
-
-## 参照ルール（重要）
-
-- `.qfai/specs` や `contracts` は **.qfai/require を参照してよい**。
-- `.qfai/require` 側から `.qfai/specs` や `contracts` を参照するのは **禁止**。

package/assets/init/.qfai/prompts.local/README.md

@@ -1,31 +0,0 @@
-# Prompts Local（利用者カスタム / Overlay）
-
-このディレクトリは **利用者が自由に編集・追加できるプロンプト資産**の置き場です。
-
-QFAI v0.7 以降は、プロンプト資産のカスタマイズ手段を **overlay（prompts.local 優先）**に一本化します。
-
-## Overlay ルール（重要）
-
-同じ相対パスのファイルが存在する場合、次の優先順位で参照する運用とします。
-
-1. `.qfai/prompts.local/<relativePath>`（存在すればこちらを優先）
-2. `.qfai/prompts/<relativePath>`（無ければ base を参照）
-
-例:
-
-- base: `.qfai/prompts/require-to-spec.md`
-- local override: `.qfai/prompts.local/require-to-spec.md`
-
-→ `prompts.local` に同じ相対パスで置けば、以降は local を読む運用にできます。
-
-## 重要な注意（サポート境界）
-
-- `.qfai/prompts/**` は **QFAI 標準資産**です（更新や `qfai init` の再実行で上書きされ得ます）。
-- 利用者が `.qfai/prompts/**` を直接編集することは **非推奨・非サポート（ほぼ禁止）**です。
-- 変更したい場合は、対象ファイルを `prompts.local` にコピーして上書きしてください。
-
-## init 再実行時の保護（契約）
-
-- `qfai init` は `.qfai/prompts.local/**` を **保護**します（`--force` を付けても上書きしません）。
-- `--force` は `.qfai/prompts/**` のみ上書きします。
-- `specs/` `contracts/` を含め、その他の領域は既存があればスキップします（上書きしません）。

package/assets/init/.qfai/rules/conventions.md

@@ -1,27 +0,0 @@
-# 互換維持 / 仕様変更の分類ルール
-
-本ドキュメントは `delta.md` の「変更区分」を一貫させるための規約です。
-
-## Compatibility（互換維持）
-
-- 既存の仕様と整合しており、期待値の変更がない
-- 既存の受入テスト/シナリオがそのまま成立する
-- 互換性の維持を前提とした改善・整理に留まる
-
-## Change/Improvement（改善/仕様変更）
-
-- 期待値や振る舞いが変更される、または明確に追加される
-- 既存の受入テスト/シナリオの修正が必要になる
-- 互換性の破壊または新しい制約が生じる
-
-## 運用ルール
-
-- `delta.md` では **必ずどちらか1つにチェック**する
-- 両方ON/両方OFFは無効（エラー）
-- 迷った場合は「影響範囲」「受入観点」を追記して明文化する
-
-## OQ表記の扱い（対象範囲の限定）
-
-- OQ表記の排除は、現行仕様として参照される場所に限定する
-- 対象例: `packages/qfai/assets/init/.qfai/`, `.github/PULL_REQUEST_TEMPLATE.md`, `README.md`, `packages/qfai/README.md`
-- 意思決定ログ/補助資料（例: `docs/examples/`）は対象外とし、履歴の削除を誘発しない

package/assets/init/.qfai/rules/pnpm.md

@@ -1,29 +0,0 @@
-# pnpm lifecycle script 許可リスト（allowlist）運用ガイド
-
-## 目的
-
-pnpm 環境で表示される `Ignored build scripts: ...` に対し、依存パッケージのビルドスクリプトを
-**安全に許可するための運用手順**を提示します。これは QFAI の validate 対象外です。
-
-## 典型的な事象
-
-- `Ignored build scripts: esbuild` などの警告が表示される
-
-## 影響例
-
-- ビルド成果物が生成されず、実行時エラーや動作不整合が起きる
-- ローカルは動くが CI で失敗するなど、環境差分が発生する
-
-## 最小運用フロー（例）
-
-1. 警告に出た依存を特定する（lockfile/依存ツリーで確認）
-2. 依存の出所・信頼性を確認する（公式パッケージ/署名/公開元など）
-3. チームで許可判断を行う（承認者・記録方法を決める）
-4. pnpm の設定（例: `onlyBuiltDependencies` など）を更新し、許可対象を管理する
-5. 変更内容を記録し、再現可能性を担保する（README/CHANGELOG など）
-
-## 注意
-
-- pnpm のバージョンや設定により手順が変わる場合があります。
-- 実際のコマンドやオプションは **pnpm の公式ドキュメント**を参照してください。
-- allowlist の判断は各プロジェクトのセキュリティ方針に従ってください。

package/assets/init/.qfai/samples/analyze/analysis.md

@@ -1,38 +0,0 @@
-# analyze 実施ログ（テンプレート）
-
-> 目的: analyze は `validate` が扱わない「意味矛盾」の候補を抽出するための **レビュー補助**です。
-> 結果は正解判定ではありません。根拠（引用）を確認し、レビューで判断してください。
-
-## メタ
-
-- 実施日: YYYY-MM-DD
-- 対象: <PR番号 / ブランチ / 変更スコープ>
-- 利用モデル/環境: <任意>
-
-## 入力（貼り付けたもの）
-
-- Spec: <spec.md / delta.md の該当範囲>
-- Scenario: <scenario.feature の該当範囲>
-- Contract（任意）: <該当契約>
-- validate/report 要約: <report.md または validate.json の要約>
-- 差分: <PR diff / 変更ファイル一覧>
-
-## 実行したプロンプト
-
-- `.qfai/prompts/analyze/spec_to_scenario.md`
-- `.qfai/prompts/analyze/spec_to_contract.md`
-- `.qfai/prompts/analyze/scenario_to_test.md`
-
-## 結果（候補）
-
-- <貼り付け>
-
-## レビュー判断
-
-- 採用（修正する）: <項目>
-- 却下（問題なし/誤検知）: <項目>
-- 保留（追加調査/議論）: <項目>
-
-## 次アクション
-
-- <誰が/何を/いつまでに>

package/assets/init/.qfai/samples/analyze/input_bundle.md

@@ -1,54 +0,0 @@
-# analyze 入力バンドル（サンプル）
-
-> 目的: `analyze` 用の入力をブレなく用意するための完成例です。
-> 本ファイルは架空の小規模機能を題材にしています。自プロジェクトではコピーして編集してください。
-
-## Project Context
-
-- 対象機能: パスワードリセット（メールでワンタイムリンクを送る）
-- 前提/制約:
-  - リンクは 15 分で失効
-  - 送信頻度制限（IP + アカウント単位）
-  - 失効後は再送が必要
-- 対象外（Non-goals）:
-  - 多要素認証
-  - 端末認証
-
-## Spec Excerpts
-
-- ユーザーがメールアドレスを入力すると、登録済みならリセットリンクを送る
-- 未登録メールでも挙動は同じに見せる（ユーザー列挙防止）
-- リンクは 15 分で失効し、失効後はエラーを表示する
-
-## Scenario Excerpts
-
-- Given 登録済みユーザーがいる
-  When パスワードリセットを要求する
-  Then リセットメールが送信される
-- Given 未登録のメールアドレス
-  When パスワードリセットを要求する
-  Then 同じメッセージが表示される（送信の有無は漏らさない）
-- Given 期限切れのリセットリンク
-  When リセットリンクを開く
-  Then 期限切れとして扱われ、再送導線が提示される
-
-## Test Excerpts
-
-- unit: `requestPasswordReset` は常に成功レスポンスを返す（登録有無を分岐しない）
-- unit: `verifyResetToken` は失効時に `TokenExpired` を返す
-- integration: 送信頻度制限が発動した場合でも同じメッセージを返す
-
-## Contract / Trace Links
-
-- Spec: SPEC-RESET-001 → Scenario: SC-RESET-001, SC-RESET-002, SC-RESET-003
-- Scenario: SC-RESET-003 → Test: tests/auth/reset.test.ts#expired
-
-## Open Concerns
-
-- 送信頻度制限のしきい値（運用で調整するか、固定か）
-- 期限切れ時のUX（単に失敗か、再送導線を必須にするか）
-
-## Non-goals
-
-- メール配信基盤の冗長化
-- 監査ログの永続化

package/assets/init/.qfai/specs/spec-0001/delta.md

@@ -1,30 +0,0 @@
-# Delta: SPEC-0001
-
-## 変更区分
-
-- [x] Compatibility（互換維持: 既存仕様と整合）
-- [ ] Change/Improvement（改善/仕様変更: 期待値の変更を含む）
-
-## 変更の要約（What）
-
-- ...
-
-## 根拠（Why）
-
-- ...
-
-## 影響範囲（Impact）
-
-- 仕様（spec.md）:
-- シナリオ（scenario.feature）:
-- 契約（contracts）:
-- 実装（src）:
-- テスト（tests）:
-
-## 受入観点（ATDD/QA）
-
-- ...
-
-## 移行メモ（任意）
-
-- ...

package/assets/init/.qfai/specs/spec-0001/scenario.feature

@@ -1,11 +0,0 @@
-@SPEC-0001
-Feature: 注文登録
-
-Rule: 承認者が存在する
-
-    # QFAI-CONTRACT-REF: UI-0001, API-0001, DB-0001, THEMA-001
-    @SC-0001 @BR-0001
-    Scenario: 承認者が承認するまで注文は確定しない
-      Given ...
-      When ...
-      Then ...

package/assets/init/.qfai/specs/spec-0001/spec.md

@@ -1,40 +0,0 @@
-# SPEC-0001: 注文登録の最小仕様（サンプル）
-
-QFAI-CONTRACT-REF: API-0001, UI-0001, DB-0001, THEMA-001
-
-> このテンプレは **最小例** です。実際の仕様に合わせて書き換えてください。
-
-## 背景
-
-- 例: 受注の登録ルールを統一し、手戻りを減らす
-
-## スコープ
-
-- 例: 新規受注の登録と承認
-
-## 非ゴール
-
-- 例: 既存受注の履歴移行は対象外
-
-## 用語
-
-- 例: 受注 = 顧客からの注文情報
-
-## 前提
-
-- 例: 承認者は1名以上配置されている
-
-## 決定事項
-
-- 例: 承認は1段階で完了とする
-
-## 業務ルール
-
-- [BR-0001][P2] 受注は承認者が承認するまで確定しない
-
-### 書き方メモ
-
-- BR は **原子ルール** として採番する（`BR-0001.1` は使わない）
-- BR には **Priority(P0〜P3)** を必ず付与する
-- BR 定義は `## 業務ルール` セクション内に置く
-- Spec では **SC ID** を参照しない