qfai 0.3.0 → 0.3.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +6 -8
- package/assets/init/.qfai/README.md +6 -5
- package/assets/init/.qfai/rules/conventions.md +21 -0
- package/assets/init/.qfai/specs/README.md +51 -0
- package/assets/init/.qfai/specs/spec-0001/delta.md +30 -0
- package/assets/init/.qfai/specs/spec-0001/scenario.md +10 -0
- package/assets/init/.qfai/{spec/spec-0001-sample.md → specs/spec-0001/spec.md} +3 -2
- package/assets/init/root/.github/workflows/qfai.yml +1 -1
- package/assets/init/root/qfai.config.yaml +5 -8
- package/dist/cli/index.cjs +619 -439
- package/dist/cli/index.cjs.map +1 -1
- package/dist/cli/index.mjs +594 -410
- package/dist/cli/index.mjs.map +1 -1
- package/dist/index.cjs +590 -393
- package/dist/index.cjs.map +1 -1
- package/dist/index.d.cts +8 -12
- package/dist/index.d.ts +8 -12
- package/dist/index.mjs +569 -368
- package/dist/index.mjs.map +1 -1
- package/package.json +3 -1
- package/assets/init/.qfai/spec/README.md +0 -82
- package/assets/init/.qfai/spec/decisions/ADR-0001.md +0 -9
- package/assets/init/.qfai/spec/decisions/README.md +0 -37
- package/assets/init/.qfai/spec/scenarios/scenarios.feature +0 -6
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "qfai",
|
|
3
|
-
"version": "0.3.
|
|
3
|
+
"version": "0.3.2",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"bin": {
|
|
6
6
|
"qfai": "./dist/cli/index.mjs"
|
|
@@ -28,6 +28,8 @@
|
|
|
28
28
|
"test": "vitest run"
|
|
29
29
|
},
|
|
30
30
|
"dependencies": {
|
|
31
|
+
"@cucumber/gherkin": "^37.0.1",
|
|
32
|
+
"@cucumber/messages": "^31.1.0",
|
|
31
33
|
"yaml": "^2.5.1"
|
|
32
34
|
},
|
|
33
35
|
"devDependencies": {
|
|
@@ -1,82 +0,0 @@
|
|
|
1
|
-
# Spec / Scenario / Decisions
|
|
2
|
-
|
|
3
|
-
このディレクトリは「仕様（Spec）」「シナリオ（Scenario）」「意思決定（ADR）」の入口です。
|
|
4
|
-
|
|
5
|
-
## 置くべきファイル
|
|
6
|
-
|
|
7
|
-
- Spec: `spec-0001-<slug>.md`（必須）
|
|
8
|
-
- Scenario: `scenarios/*.feature`
|
|
9
|
-
- Decisions: `decisions/ADR-0001.md` など
|
|
10
|
-
|
|
11
|
-
## 最小例（Spec）
|
|
12
|
-
|
|
13
|
-
```md
|
|
14
|
-
# SPEC-0001: 注文登録の最小要件
|
|
15
|
-
|
|
16
|
-
## 背景
|
|
17
|
-
|
|
18
|
-
- 例: 受注の登録ルールを明文化し、手戻りを減らすため
|
|
19
|
-
|
|
20
|
-
## スコープ
|
|
21
|
-
|
|
22
|
-
- 例: 新規受注の登録と承認
|
|
23
|
-
|
|
24
|
-
## 非ゴール
|
|
25
|
-
|
|
26
|
-
- 例: 既存受注の履歴移行は対象外
|
|
27
|
-
|
|
28
|
-
## 用語
|
|
29
|
-
|
|
30
|
-
- 例: 受注 = 顧客からの注文情報
|
|
31
|
-
|
|
32
|
-
## 前提
|
|
33
|
-
|
|
34
|
-
- 例: 承認者は1名以上配置されている
|
|
35
|
-
|
|
36
|
-
## 決定事項
|
|
37
|
-
|
|
38
|
-
- 例: 承認は1段階で完了とする
|
|
39
|
-
|
|
40
|
-
## 業務ルール
|
|
41
|
-
|
|
42
|
-
- [BR-0001] (P2) 受注は承認者が承認するまで確定しない
|
|
43
|
-
- [BR-0002] (P1) 承認済みの受注のみ出荷依頼に進める
|
|
44
|
-
```
|
|
45
|
-
|
|
46
|
-
## BR の書き方（重要）
|
|
47
|
-
|
|
48
|
-
- **1 ルール = 1 BR** を守る
|
|
49
|
-
- 小項目がある場合は **別 BR を採番**する（`BR-0001.1` は使わない）
|
|
50
|
-
- 参照は常に BR ID を使う
|
|
51
|
-
- Priority は **P0/P1/P2/P3 のいずれか** を必ず付与する（迷う場合は P2 から開始）
|
|
52
|
-
|
|
53
|
-
## Scenario の最小要件
|
|
54
|
-
|
|
55
|
-
- `@SC-xxxx` / `@SPEC-xxxx` / `@BR-xxxx` をタグで明示
|
|
56
|
-
- タグ行は **Scenario 行の直前** に置く
|
|
57
|
-
- Scenario は複数の SPEC を参照してよい（`@SPEC-xxxx` を複数記載可能）
|
|
58
|
-
- `Given / When / Then` を含める
|
|
59
|
-
- UI/API/DATA 契約に接続する（トレーサビリティのエラー回避）
|
|
60
|
-
|
|
61
|
-
## CI でチェックされること（抜粋）
|
|
62
|
-
|
|
63
|
-
- Spec: 必須セクションの有無（H2）、SPEC/BR ID の存在、BR Priority、ID 形式（`PREFIX-0001`）、Contract 参照の実在性
|
|
64
|
-
- Scenario: SC/SPEC/BR の参照、Given/When/Then の有無、参照IDの実在性
|
|
65
|
-
- Traceability: BR→SC、SC→契約（UI/API/DATA）の接続、BR の所属 SPEC 整合
|
|
66
|
-
- IDs: 定義 ID の重複検知（Spec/Scenario/Contracts）
|
|
67
|
-
|
|
68
|
-
## 依存関係
|
|
69
|
-
|
|
70
|
-
- Spec → Scenario → Contracts
|
|
71
|
-
- Spec → Contracts（参照は許容）
|
|
72
|
-
- Decisions（ADR）→ Spec / BR
|
|
73
|
-
|
|
74
|
-
## 良い例 / 悪い例
|
|
75
|
-
|
|
76
|
-
- 良い例: `BR-0001` が Scenario で参照され、UI/API/DATA のいずれかに接続している
|
|
77
|
-
- 悪い例: Spec に `SC-xxxx` を書く（Spec は SC を参照しない）
|
|
78
|
-
|
|
79
|
-
## 良い運用 / 悪い運用
|
|
80
|
-
|
|
81
|
-
- 良い運用: Spec/Scenario/Contracts を同じ ID でつなぐ
|
|
82
|
-
- 悪い運用: Spec の BR が Scenario に出てこない（孤立）
|
|
@@ -1,37 +0,0 @@
|
|
|
1
|
-
# ADR (Architecture Decision Record)
|
|
2
|
-
|
|
3
|
-
ADR は「なぜその判断をしたか」を記録するための軽量な意思決定ログです。
|
|
4
|
-
|
|
5
|
-
## いつ書くか
|
|
6
|
-
|
|
7
|
-
- 仕様の前提や制約が変わるとき
|
|
8
|
-
- 技術選定や設計方針を決めたとき
|
|
9
|
-
- 重要なトレードオフがあるとき
|
|
10
|
-
|
|
11
|
-
## 最小例
|
|
12
|
-
|
|
13
|
-
```md
|
|
14
|
-
# ADR-0001: 承認フローは1段階にする
|
|
15
|
-
|
|
16
|
-
- Status: Proposed
|
|
17
|
-
- Context: 承認者を増やすと運用が複雑になる
|
|
18
|
-
- Decision: 現時点では1段階の承認に固定する
|
|
19
|
-
- Consequences: 多段承認が必要な場合は拡張が必要
|
|
20
|
-
- Related: BR-0001, SPEC-0001
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
## CI でチェックされること（抜粋）
|
|
24
|
-
|
|
25
|
-
- ID 形式（`PREFIX-0001`。ADR を含む）
|
|
26
|
-
- 参照 ID の整合性（トレーサビリティ）
|
|
27
|
-
- 必須フィールド（Status/Context/Decision/Consequences）の有無
|
|
28
|
-
|
|
29
|
-
## 依存関係
|
|
30
|
-
|
|
31
|
-
- ADR は Spec / BR と一緒に参照される
|
|
32
|
-
- Scenario/Contracts から参照されることは少ない
|
|
33
|
-
|
|
34
|
-
## 良い例 / 悪い例
|
|
35
|
-
|
|
36
|
-
- 良い例: Context/Decision/Consequences が簡潔に書かれている
|
|
37
|
-
- 悪い例: Decision が空のまま放置されている
|