desu-e2etesuto-nopiisu-wo-shim (#149)

* takt: desu-e2etesuto-nopiisu-wo-shim

* 動的にbuiltinを処理
This commit is contained in:
nrs 2026-02-09 00:32:49 +09:00 committed by GitHub
parent b5eef8d3fa
commit cc63f4769d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
15 changed files with 790 additions and 1 deletions

View File

@ -0,0 +1,52 @@
Implement unit tests according to the test plan.
Refer only to files within the Report Directory shown in the Piece Context. Do not search or reference other report directories.
**Important: Do NOT modify production code. Only test files may be edited.**
**Actions:**
1. Review the test plan report
2. Implement the planned test cases
3. Run tests and verify all pass
4. Confirm existing tests are not broken
**Test implementation constraints:**
- Follow the project's existing test patterns (naming conventions, directory structure, helpers)
- Write tests in Given-When-Then structure
- One concept per test. Do not mix multiple concerns in a single test
**Scope output contract (create at the start of implementation):**
```markdown
# Change Scope Declaration
## Task
{One-line task summary}
## Planned changes
| Type | File |
|------|------|
| Create | `src/__tests__/example.test.ts` |
## Estimated size
Small / Medium / Large
## Impact area
- {Affected modules or features}
```
**Decisions output contract (at implementation completion, only if decisions were made):**
```markdown
# Decision Log
## 1. {Decision}
- **Context**: {Why the decision was needed}
- **Options considered**: {List of options}
- **Rationale**: {Reason for the choice}
```
**Required output (include headings)**
## Work results
- {Summary of actions taken}
## Changes made
- {Summary of changes}
## Test results
- {Command executed and results}

View File

@ -0,0 +1,11 @@
Analyze the target code and identify missing unit tests.
**Note:** If a Previous Response exists, this is a replan due to rejection.
Revise the test plan taking that feedback into account.
**Actions:**
1. Read the target module source code and understand its behavior, branches, and state transitions
2. Read existing tests and identify what is already covered
3. Identify missing test cases (happy path, error cases, boundary values, edge cases)
4. Determine test strategy (mock approach, existing test helper usage, fixture design)
5. Provide concrete guidelines for the test implementer

View File

@ -0,0 +1,14 @@
Review the changes from a test quality perspective.
**Review criteria:**
- Whether all test plan items are covered
- Test quality (Given-When-Then structure, independence, reproducibility)
- Test naming conventions
- Completeness (unnecessary tests, missing cases)
- Appropriateness of mocks and fixtures
## Judgment Procedure
1. Cross-reference the test plan report ({report:00-test-plan.md}) with the implemented tests
2. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
3. If there is even one blocking issue, judge as REJECT

View File

@ -0,0 +1,24 @@
```markdown
# Test Plan
## Target Modules
{List of modules to analyze}
## Existing Test Analysis
| Module | Existing Tests | Coverage Status |
|--------|---------------|-----------------|
| `src/xxx.ts` | `xxx.test.ts` | {Coverage status} |
## Missing Test Cases
| # | Target | Test Case | Priority | Reason |
|---|--------|-----------|----------|--------|
| 1 | `src/xxx.ts` | {Test case summary} | High/Medium/Low | {Reason} |
## Test Strategy
- {Mock approach}
- {Fixture design}
- {Test helper usage}
## Implementation Guidelines
- {Concrete instructions for the test implementer}
```

View File

@ -0,0 +1,25 @@
# Test Planner
You are a **test analysis and planning specialist**. You understand the behavior of target code, analyze existing test coverage, and systematically identify missing test cases.
## Role Boundaries
**Do:**
- Analyze target code behavior, branches, and state transitions
- Analyze existing test coverage
- Identify missing test cases (happy path, error cases, boundary values, edge cases)
- Determine test strategy (mock approach, fixture design, test helper usage)
- Provide concrete guidelines for test implementers
**Don't:**
- Plan production code changes (Planner's job)
- Implement test code (Coder's job)
- Review code (Reviewer's job)
## Behavioral Principles
- Read the code before planning. Don't list test cases based on guesses
- Always check existing tests. Don't duplicate already-covered scenarios
- Prioritize tests: business logic and state transitions > edge cases > simple CRUD
- Provide instructions at a granularity that prevents test implementers from hesitating
- Follow the project's existing test patterns. Don't propose novel conventions

View File

@ -10,6 +10,7 @@ piece_categories:
pieces:
- review-fix-minimal
- review-only
- unit-test
🎨 Frontend: {}
⚙️ Backend: {}
🔧 Expert:

View File

@ -0,0 +1,267 @@
name: unit-test
description: Unit test focused piece (test analysis → test implementation → review → fix)
max_iterations: 20
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
qa: ../policies/qa.md
knowledge:
architecture: ../knowledge/architecture.md
backend: ../knowledge/backend.md
personas:
test-planner: ../personas/test-planner.md
coder: ../personas/coder.md
ai-antipattern-reviewer: ../personas/ai-antipattern-reviewer.md
architecture-reviewer: ../personas/architecture-reviewer.md
qa-reviewer: ../personas/qa-reviewer.md
supervisor: ../personas/supervisor.md
instructions:
plan-test: ../instructions/plan-test.md
implement-test: ../instructions/implement-test.md
ai-review: ../instructions/ai-review.md
ai-fix: ../instructions/ai-fix.md
arbitrate: ../instructions/arbitrate.md
review-test: ../instructions/review-test.md
fix: ../instructions/fix.md
supervise: ../instructions/supervise.md
initial_movement: plan_test
loop_monitors:
- cycle:
- ai_review
- ai_fix
threshold: 3
judge:
persona: supervisor
instruction_template: |
The ai_review ↔ ai_fix loop has repeated {cycle_count} times.
Review the reports from each cycle and determine whether this loop
is healthy (making progress) or unproductive (repeating the same issues).
**Reports to reference:**
- AI Review results: {report:04-ai-review.md}
**Judgment criteria:**
- Are new issues being found/fixed in each cycle?
- Are the same findings being repeated?
- Are fixes actually being applied?
rules:
- condition: Healthy (making progress)
next: ai_review
- condition: Unproductive (no improvement)
next: review_test
movements:
- name: plan_test
edit: false
persona: test-planner
policy: testing
knowledge:
- architecture
- backend
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
rules:
- condition: Test plan complete
next: implement_test
- condition: User is asking a question (not a test task)
next: COMPLETE
- condition: Requirements unclear, insufficient info
next: ABORT
appendix: |
Clarifications needed:
- {Question 1}
- {Question 2}
instruction: plan-test
output_contracts:
report:
- name: 00-test-plan.md
format: test-plan
- name: implement_test
edit: true
persona: coder
policy:
- coding
- testing
session: refresh
knowledge:
- backend
- architecture
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: Test implementation complete
next: ai_review
- condition: No implementation (report only)
next: ai_review
- condition: Cannot proceed, insufficient info
next: ai_review
- condition: User input required
next: implement_test
requires_user_input: true
interactive_only: true
instruction: implement-test
output_contracts:
report:
- Scope: 02-coder-scope.md
- Decisions: 03-coder-decisions.md
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
policy:
- review
- ai-antipattern
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: No AI-specific issues
next: review_test
- condition: AI-specific issues found
next: ai_fix
instruction: ai-review
output_contracts:
report:
- name: 04-ai-review.md
format: ai-review
- name: ai_fix
edit: true
persona: coder
policy:
- coding
- testing
session: refresh
knowledge:
- backend
- architecture
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI issues fixed
next: ai_review
- condition: No fix needed (verified target files/spec)
next: ai_no_fix
- condition: Cannot proceed, insufficient info
next: ai_no_fix
instruction: ai-fix
- name: ai_no_fix
edit: false
persona: architecture-reviewer
policy: review
allowed_tools:
- Read
- Glob
- Grep
rules:
- condition: ai_review's findings are valid (fix required)
next: ai_fix
- condition: ai_fix's judgment is valid (no fix needed)
next: review_test
instruction: arbitrate
- name: review_test
edit: false
persona: qa-reviewer
policy:
- review
- qa
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
next: supervise
- condition: needs_fix
next: fix
instruction: review-test
output_contracts:
report:
- name: 05-qa-review.md
format: qa-review
- name: fix
edit: true
persona: coder
policy:
- coding
- testing
session: refresh
knowledge:
- backend
- architecture
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: Fix complete
next: review_test
- condition: Cannot proceed, insufficient info
next: plan_test
instruction: fix
- name: supervise
edit: false
persona: supervisor
policy: review
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
rules:
- condition: All checks passed
next: COMPLETE
- condition: Requirements unmet, tests failing, build errors
next: plan_test
instruction: supervise
output_contracts:
report:
- Validation: 06-supervisor-validation.md
- Summary: summary.md
report_formats:
test-plan: ../output-contracts/test-plan.md
ai-review: ../output-contracts/ai-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md

View File

@ -0,0 +1,52 @@
テスト計画に従って単体テストを実装してください。
Piece Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
**重要: プロダクションコードは変更しないでください。テストファイルのみ編集可能です。**
**やること:**
1. テスト計画のレポートを確認する
2. 計画されたテストケースを実装する
3. テストを実行して全パスを確認する
4. 既存テストが壊れていないことを確認する
**テスト実装の制約:**
- プロジェクトの既存テストパターン(命名規約、ディレクトリ構成、ヘルパー)に従う
- Given-When-Then 構造で記述する
- 1テスト1概念。複数の関心事を1テストに混ぜない
**Scope出力契約実装開始時に作成:**
```markdown
# 変更スコープ宣言
## タスク
{タスクの1行要約}
## 変更予定
| 種別 | ファイル |
|------|---------|
| 作成 | `src/__tests__/example.test.ts` |
## 推定規模
Small / Medium / Large
## 影響範囲
- {影響するモジュールや機能}
```
**Decisions出力契約実装完了時、決定がある場合のみ:**
```markdown
# 決定ログ
## 1. {決定内容}
- **背景**: {なぜ決定が必要だったか}
- **検討した選択肢**: {選択肢リスト}
- **理由**: {選んだ理由}
```
**必須出力(見出しを含める)**
## 作業結果
- {実施内容の要約}
## 変更内容
- {変更内容の要約}
## テスト結果
- {実行コマンドと結果}

View File

@ -0,0 +1,11 @@
対象コードを分析し、不足している単体テストを洗い出してください。
**注意:** Previous Responseがある場合は差し戻しのため、
その内容を踏まえてテスト計画を見直してください。
**やること:**
1. 対象モジュールのソースコードを読み、振る舞い・分岐・状態遷移を理解する
2. 既存テストを読み、カバーされている観点を把握する
3. 不足しているテストケース(正常系・異常系・境界値・エッジケース)を洗い出す
4. テスト方針(モック戦略、既存テストヘルパーの活用、フィクスチャ設計)を決める
5. テスト実装者向けの具体的なガイドラインを出す

View File

@ -0,0 +1,14 @@
テスト品質の観点から変更をレビューしてください。
**レビュー観点:**
- テスト計画の観点がすべてカバーされているか
- テスト品質Given-When-Then構造、独立性、再現性
- テスト命名規約
- 過不足(不要なテスト、足りないケース)
- モック・フィクスチャの適切さ
## 判定手順
1. テスト計画レポート({report:00-test-plan.md})と実装されたテストを突合する
2. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
3. ブロッキング問題が1件でもあればREJECTと判定する

View File

@ -0,0 +1,24 @@
```markdown
# テスト計画
## 対象モジュール
{分析対象のモジュール一覧}
## 既存テストの分析
| モジュール | 既存テスト | カバレッジ状況 |
|-----------|-----------|--------------|
| `src/xxx.ts` | `xxx.test.ts` | {カバー状況} |
## 不足テストケース
| # | 対象 | テストケース | 優先度 | 理由 |
|---|------|------------|--------|------|
| 1 | `src/xxx.ts` | {テストケース概要} | 高/中/低 | {理由} |
## テスト方針
- {モック戦略}
- {フィクスチャ設計}
- {テストヘルパー活用}
## 実装ガイドライン
- {テスト実装者向けの具体的指示}
```

View File

@ -0,0 +1,25 @@
# Test Planner
あなたはテスト分析と計画の専門家です。対象コードの振る舞いを理解し、既存テストのカバレッジを分析して、不足しているテストケースを体系的に洗い出す。
## 役割の境界
**やること:**
- 対象コードの振る舞い・分岐・状態遷移を読み解く
- 既存テストのカバレッジを分析する
- 不足しているテストケース(正常系・異常系・境界値・エッジケース)を洗い出す
- テスト戦略(モック方針、フィクスチャ設計、テストヘルパー活用)を決める
- テスト実装者への具体的なガイドラインを出す
**やらないこと:**
- プロダクションコードの変更計画Plannerの仕事
- テストコードの実装Coderの仕事
- コードレビューReviewerの仕事
## 行動姿勢
- コードを読んでから計画する。推測でテストケースを列挙しない
- 既存テストを必ず確認する。カバー済みの観点を重複して計画しない
- テスト優先度を付ける。ビジネスロジック・状態遷移 > エッジケース > 単純なCRUD
- テスト実装者が迷わない粒度で指示を出す
- プロジェクトの既存テストパターンに合わせる。独自の書き方を提案しない

View File

@ -10,6 +10,7 @@ piece_categories:
pieces:
- review-fix-minimal
- review-only
- unit-test
🎨 フロントエンド: {}
⚙️ バックエンド: {}
🔧 エキスパート:

View File

@ -0,0 +1,267 @@
name: unit-test
description: 単体テスト追加に特化したピース(テスト分析→テスト実装→レビュー→修正)
max_iterations: 20
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
qa: ../policies/qa.md
knowledge:
architecture: ../knowledge/architecture.md
backend: ../knowledge/backend.md
personas:
test-planner: ../personas/test-planner.md
coder: ../personas/coder.md
ai-antipattern-reviewer: ../personas/ai-antipattern-reviewer.md
architecture-reviewer: ../personas/architecture-reviewer.md
qa-reviewer: ../personas/qa-reviewer.md
supervisor: ../personas/supervisor.md
instructions:
plan-test: ../instructions/plan-test.md
implement-test: ../instructions/implement-test.md
ai-review: ../instructions/ai-review.md
ai-fix: ../instructions/ai-fix.md
arbitrate: ../instructions/arbitrate.md
review-test: ../instructions/review-test.md
fix: ../instructions/fix.md
supervise: ../instructions/supervise.md
initial_movement: plan_test
loop_monitors:
- cycle:
- ai_review
- ai_fix
threshold: 3
judge:
persona: supervisor
instruction_template: |
ai_review と ai_fix のループが {cycle_count} 回繰り返されました。
各サイクルのレポートを確認し、このループが健全(進捗がある)か、
非生産的(同じ問題を繰り返している)かを判断してください。
**参照するレポート:**
- AIレビュー結果: {report:04-ai-review.md}
**判断基準:**
- 各サイクルで新しい問題が発見・修正されているか
- 同じ指摘が繰り返されていないか
- 修正が実際に反映されているか
rules:
- condition: 健全(進捗あり)
next: ai_review
- condition: 非生産的(改善なし)
next: review_test
movements:
- name: plan_test
edit: false
persona: test-planner
policy: testing
knowledge:
- architecture
- backend
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
rules:
- condition: テスト計画が完了
next: implement_test
- condition: ユーザーが質問をしている(テスト追加タスクではない)
next: COMPLETE
- condition: 要件が不明確、情報不足
next: ABORT
appendix: |
確認事項:
- {質問1}
- {質問2}
instruction: plan-test
output_contracts:
report:
- name: 00-test-plan.md
format: test-plan
- name: implement_test
edit: true
persona: coder
policy:
- coding
- testing
session: refresh
knowledge:
- backend
- architecture
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: テスト実装完了
next: ai_review
- condition: 実装未着手(レポートのみ)
next: ai_review
- condition: 判断できない、情報不足
next: ai_review
- condition: ユーザー入力が必要
next: implement_test
requires_user_input: true
interactive_only: true
instruction: implement-test
output_contracts:
report:
- Scope: 02-coder-scope.md
- Decisions: 03-coder-decisions.md
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
policy:
- review
- ai-antipattern
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: AI特有の問題なし
next: review_test
- condition: AI特有の問題あり
next: ai_fix
instruction: ai-review
output_contracts:
report:
- name: 04-ai-review.md
format: ai-review
- name: ai_fix
edit: true
persona: coder
policy:
- coding
- testing
session: refresh
knowledge:
- backend
- architecture
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: AI問題の修正完了
next: ai_review
- condition: 修正不要(指摘対象ファイル/仕様の確認済み)
next: ai_no_fix
- condition: 判断できない、情報不足
next: ai_no_fix
instruction: ai-fix
- name: ai_no_fix
edit: false
persona: architecture-reviewer
policy: review
allowed_tools:
- Read
- Glob
- Grep
rules:
- condition: ai_reviewの指摘が妥当修正すべき
next: ai_fix
- condition: ai_fixの判断が妥当修正不要
next: review_test
instruction: arbitrate
- name: review_test
edit: false
persona: qa-reviewer
policy:
- review
- qa
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
next: supervise
- condition: needs_fix
next: fix
instruction: review-test
output_contracts:
report:
- name: 05-qa-review.md
format: qa-review
- name: fix
edit: true
persona: coder
policy:
- coding
- testing
session: refresh
knowledge:
- backend
- architecture
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
permission_mode: edit
rules:
- condition: 修正完了
next: review_test
- condition: 判断できない、情報不足
next: plan_test
instruction: fix
- name: supervise
edit: false
persona: supervisor
policy: review
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
rules:
- condition: すべて問題なし
next: COMPLETE
- condition: 要求未達成、テスト失敗、ビルドエラー
next: plan_test
instruction: supervise
output_contracts:
report:
- Validation: 06-supervisor-validation.md
- Summary: summary.md
report_formats:
test-plan: ../output-contracts/test-plan.md
ai-review: ../output-contracts/ai-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md

View File

@ -25,6 +25,7 @@ vi.mock('../infra/config/global/globalConfig.js', () => ({
// --- Imports (after mocks) ---
import { loadPiece } from '../infra/config/index.js';
import { listBuiltinPieceNames } from '../infra/config/loaders/pieceResolver.js';
// --- Test helpers ---
@ -45,7 +46,7 @@ describe('Piece Loader IT: builtin piece loading', () => {
rmSync(testDir, { recursive: true, force: true });
});
const builtinNames = ['default', 'minimal', 'expert', 'expert-cqrs', 'coding', 'passthrough', 'compound-eye', 'research', 'magi', 'review-only', 'review-fix-minimal', 'structural-reform'];
const builtinNames = listBuiltinPieceNames({ includeDisabled: true });
for (const name of builtinNames) {
it(`should load builtin piece: ${name}`, () => {