qfai 1.0.3 → 1.0.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "qfai",
-  "version": "1.0.3",
+  "version": "1.0.4",
   "description": "Quality-first AI-driven development toolkit (SDD × ATDD × TDD).",
   "license": "MIT",
   "repository": {

package/assets/init/.qfai/promptpack/modes/change.md

@@ -1,5 +0,0 @@
-# Mode: Change
-
-- 期待値/挙動/互換性が変わる場合は Change を選ぶ
-- 仕様変更の根拠（Why）を delta.md に必ず記録する
-- 影響範囲、移行・運用への影響、受入テスト更新方針を明記する

package/assets/init/.qfai/promptpack/modes/compatibility.md

@@ -1,6 +0,0 @@
-# Mode: Compatibility
-
-- 既存仕様との整合を最優先にする
-- 期待値/外部I/Fの変更は行わない（変更がある場合は Change へ）
-- 影響範囲を最小化し、回帰テストを重視する
-- 分類と根拠（Why）、影響範囲、受入テスト更新方針を明記する

package/assets/init/.qfai/promptpack/steering/compatibility-vs-change.md

@@ -1,42 +0,0 @@
-# Compatibility vs Change
-
-互換維持と仕様変更の区分は `rules/conventions.md` に従う。
-
-- 互換維持: 既存の期待値を変えない
-- 仕様変更: 期待値/挙動が変わる
-
-必ず `delta.md` に区分と根拠を記録する。
-
----
-
-## 最小ルール（迷ったらこれ）
-
-- **既存の利用者がそのまま手順・解釈で運用できる**: Compatibility
-- **既存の利用者が手順変更・解釈変更・レビュー基準変更を迫られる**: Change/Improvement
-
-「見た目だけ」「文章だけ」でも、運用で機械消費されている可能性がある場合は慎重に扱い、根拠を `delta.md` に残す。
-
----
-
-## 具体例（最低10件）
-
-| 変更内容                                                      | 区分               | QA/レビュー観点                                      |
-| ------------------------------------------------------------- | ------------------ | ---------------------------------------------------- |
-| README の誤字修正、リンク切れ修正                             | Compatibility      | 誤誘導が減る。既存運用は不変。                       |
-| report（text/markdown）の表現改善・並び順安定化（意味は不変） | Compatibility      | 人間レビューの短縮。出力の“解釈”が変わらないこと。   |
-| report.json のフィールド追加/並び変更（非契約を維持）         | Compatibility      | 非契約を明記し続ける。機械消費ユーザーへの注意喚起。 |
-| validate の文言改善（issue code/意味/失敗条件は不変）         | Compatibility      | 次アクションが明確になる。誤爆やノイズ増がないこと。 |
-| validate で新しい issue code を追加（warning/info）           | Change/Improvement | CIの表示が変わる。ノイズ/誤検知の受容可否。          |
-| validate の fail 条件を変更（error→warning で落ちる等）       | Change/Improvement | Hard Gate が増減する。既存CIが壊れないか。           |
-| init の生成物構成を変更（新規ファイル追加）                   | Change/Improvement | 既存リポジトリへの導入影響。上書き/衝突/運用導線。   |
-| init が既存ファイルを上書きする/保護対象を変える              | Change/Improvement | 事故リスクが高い。保護の回帰テスト必須。             |
-| Spec/Scenario/Contract のID規約を変更                         | Change/Improvement | 既存資産が無効化され得る。移行ガイド必須。           |
-| overlay の優先順位/探索規則を変更                             | Change/Improvement | 既存の prompts.local 運用が壊れる。回帰テスト必須。  |
-
----
-
-## QA/レビュー時の判断テンプレ
-
-- **修正が必要**: Hard Gate を増やしていないか、既存の運用手順を壊していないか、保護領域（prompts.local）が破壊されないか
-- **許容**: 誤誘導削減、説明の具体化、並び順の安定化などで、意味・失敗条件が変わらないもの
-- **要議論**: report.json の変更、validate の新ルール追加、init生成物の変更（CI/運用への波及が読みにくいもの）

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/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
-
-- メール配信基盤の冗長化
-- 監査ログの永続化