エージェントをpureに

This commit is contained in:
nrslib 2026-01-26 10:30:42 +09:00
parent 02f4dffff6
commit 3d3e970497
12 changed files with 11 additions and 798 deletions

View File

@ -120,87 +120,13 @@ AI-generated code has unique characteristics:
**Note:** Scope creep is noted as a warning but doesn't warrant REJECT alone. Some tasks require large changes. **Note:** Scope creep is noted as a warning but doesn't warrant REJECT alone. Some tasks require large changes.
## Report Output ## Output Format
**Output review results to file.**
Output to the path specified in the workflow's `Report File`.
### Report Format
```markdown
# AI-Generated Code Review
## Result: APPROVE / REJECT
## Summary
{One sentence summarizing result}
## Verified Items
| Aspect | Result | Notes |
|--------|--------|-------|
| Assumption validity | ✅ | - |
| API/Library existence | ✅ | - |
| Context fit | ✅ | Naming conventions OK |
| Scope | ⚠️ | Minor additions |
## Issues (if REJECT)
| # | Category | Location | Issue |
|---|----------|----------|-------|
| 1 | Hallucinated API | `src/auth.ts:23` | `jwt.verifyAsync` doesn't exist |
## Coder Decision Log Review
- Decisions are sound / Issues with decisions / No decision log
```
## Cognitive Load Reduction Guidelines
**You are positioned in the middle of a multi-stage review. Your report will be read by subsequent reviewers (Security, Supervisor, humans).**
### Principle: Don't Write If No Issues
| Situation | Report Length |
|-----------|---------------|
| No issues | Summary 1 line + check table only (10 lines or less) |
| Minor suggestions | + Suggestions 1-2 lines (15 lines or less) |
| Issues found | + Issues in table format (25 lines or less) |
| Critical issues | + Detailed explanation (40 lines or less) |
### Don't Write
- Things other reviewers will check (design → Architect, vulnerabilities → Security)
- Detailed explanations for aspects with no issues
- General lectures on best practices
### Do Write
- Conclusion first (Inverted Pyramid)
- Issues in table format for visual clarity
- Evidence of "why this is AI-specific" in one sentence
## Output Format (stdout)
| Situation | Tag | | Situation | Tag |
|-----------|-----| |-----------|-----|
| No AI-specific issues | `[AI_REVIEW:APPROVE]` | | No AI-specific issues | `[AI_REVIEW:APPROVE]` |
| Issues found | `[AI_REVIEW:REJECT]` | | Issues found | `[AI_REVIEW:REJECT]` |
### REJECT Structure
```
Report output: {Report File}
[AI_REVIEW:REJECT]
Issues: {N}: {categories comma-separated}
```
### APPROVE Structure
```
Report output: {Report File}
[AI_REVIEW:APPROVE]
```
## Important ## Important
**Focus on AI-specific issues.** Don't duplicate what Architect or Security reviewers will check. **Focus on AI-specific issues.** Don't duplicate what Architect or Security reviewers will check.

View File

@ -284,45 +284,7 @@ Alternatives:
- Minor issues you want fixed before proceeding to next step - Minor issues you want fixed before proceeding to next step
- Examples: naming improvements, small refactoring, adding comments - Examples: naming improvements, small refactoring, adding comments
## Report Output ## Output Format
**Output review results to file.**
Output to the path specified in the workflow's `Report File`.
### Report Format
```markdown
# Architecture Review
## Result: APPROVE / REJECT
## Summary
{1-2 sentences summarizing result}
## Reviewed Perspectives
- [x] Structure & Design
- [x] Code Quality
- [x] Change Scope
## Issues (if REJECT)
| # | Location | Problem | Fix |
|---|----------|---------|-----|
| 1 | `src/user.ts:42` | Multiple responsibilities in one file | Split into auth/permission/profile |
## Positive Points (optional)
- Appropriate module organization
## Improvement Suggestions (optional, non-blocking)
- Consider organizing `utils/` in the future
```
**Cognitive load reduction rules:**
- APPROVE + no issues → Summary only (5 lines or less)
- APPROVE + minor suggestions → Summary + suggestions (15 lines or less)
- REJECT → Issues in table format (30 lines or less)
## Output Format (stdout)
| Situation | Tag | | Situation | Tag |
|-----------|-----| |-----------|-----|
@ -330,38 +292,6 @@ Output to the path specified in the workflow's `Report File`.
| Improvements needed (minor) | `[ARCHITECT:IMPROVE]` | | Improvements needed (minor) | `[ARCHITECT:IMPROVE]` |
| Issues require fixes | `[ARCHITECT:REJECT]` | | Issues require fixes | `[ARCHITECT:REJECT]` |
### REJECT Structure
```
Report output: {Report File}
[ARCHITECT:REJECT]
Issues: {N}. See report for details.
Main issue: {Most important issue}
```
### APPROVE Structure
```
Report output: {Report File}
[ARCHITECT:APPROVE]
Design and structure OK.
```
### IMPROVE Structure
```
Report output: {Report File}
[ARCHITECT:IMPROVE]
Improvements: {N}. See report for details.
Main improvement: {Most important improvement}
```
### Output Examples ### Output Examples
**REJECT case:** **REJECT case:**

View File

@ -93,64 +93,6 @@ Perform self-check after implementation.
**Output `[DONE]` only after all checks pass.** **Output `[DONE]` only after all checks pass.**
## Report Output
**Output the following reports for reviewers (AI and human).**
Output to the paths specified in the workflow's `Report Files`.
### Files to Output
#### 1. Change Scope Declaration
Create at implementation start (output to workflow's `Scope` path):
```markdown
# Change Scope Declaration
## Task
{One-line task summary}
## Planned Changes
| Type | File |
|------|------|
| Create | `src/auth/service.ts` |
| Create | `tests/auth.test.ts` |
| Modify | `src/routes.ts` |
## Estimated Size
Small (~150 lines)
## Impact Scope
- Auth module only
- No impact on existing APIs
```
#### 2. Decision Log
Create on completion (output to workflow's `Decisions` path, only if decisions were made):
```markdown
# Decision Log
## 1. Chose JWT (not session cookies)
- **Background**: Stateless authentication needed
- **Options considered**: JWT / Session Cookies / OAuth
- **Reason**: Fits horizontal scaling, matches existing patterns
## 2. Assumption: User ID is UUID format
- **Basis**: Existing `users` table definition
- **If wrong**: Type definition changes needed
```
**Note**: No need to record obvious decisions. Only non-obvious choices.
### When to Record
- When choosing from multiple valid approaches
- When making assumptions about unclear requirements
- When deviating from common patterns
- When making tradeoffs
## Code Principles ## Code Principles
| Principle | Guideline | | Principle | Guideline |
@ -218,12 +160,7 @@ Always include these tags when work is complete:
**On implementation complete:** **On implementation complete:**
``` ```
Reports output: Implementation complete.
- `{Report Directory}/01-coder-scope.md`
- `{Report Directory}/02-coder-decisions.md`
### Summary
Implemented task "User authentication".
- Created: `src/auth/service.ts`, `tests/auth.test.ts` - Created: `src/auth/service.ts`, `tests/auth.test.ts`
- Modified: `src/routes.ts` - Modified: `src/routes.ts`

View File

@ -41,33 +41,6 @@ Determine the implementation direction:
- Points to be careful about - Points to be careful about
- Items requiring confirmation - Items requiring confirmation
## Report Output
Output to the path specified in the workflow's `Report File`.
### Report Format
```markdown
# Task Plan
## Original Request
{User's request as-is}
## Analysis Results
### Objective
{What needs to be achieved}
### Scope
{Impact scope}
### Implementation Approach
{How to proceed}
## Clarifications Needed (if any)
- {Unclear points or items requiring confirmation}
```
## Judgment Criteria ## Judgment Criteria
| Situation | Judgment | | Situation | Judgment |
@ -82,16 +55,6 @@ Output to the path specified in the workflow's `Report File`.
| Analysis complete | `[PLANNER:DONE]` | | Analysis complete | `[PLANNER:DONE]` |
| Insufficient info | `[PLANNER:BLOCKED]` | | Insufficient info | `[PLANNER:BLOCKED]` |
### DONE Output Structure
```
Report output: {Report File}
[PLANNER:DONE]
Task analysis complete. Proceeding to implement step.
```
### BLOCKED Output Structure ### BLOCKED Output Structure
``` ```

View File

@ -179,69 +179,13 @@ if (!safePath.startsWith(path.resolve(baseDir))) {
| Minor issues/warnings only | APPROVE (note warnings) | | Minor issues/warnings only | APPROVE (note warnings) |
| No security issues | APPROVE | | No security issues | APPROVE |
## Report Output ## Output Format
**Output security review results to file.**
Output to the path specified in the workflow's `Report File`.
### Report Format
```markdown
# Security Review
## Result: APPROVE / REJECT
## Severity: None / Low / Medium / High / Critical
## Check Results
| Category | Result | Notes |
|----------|--------|-------|
| Injection | ✅ | - |
| Auth/Authz | ✅ | - |
| Data Protection | ⚠️ | Warning |
| Dependencies | ✅ | - |
## Vulnerabilities (if REJECT)
| # | Severity | Type | Location | Fix |
|---|----------|------|----------|-----|
| 1 | High | SQLi | `src/db.ts:42` | Use parameterized query |
## Warnings (non-blocking)
- Consider adding rate limiting
```
**Cognitive load reduction:**
- No issues → Check table only (10 lines or less)
- Warnings → + Warnings 1-2 lines (15 lines or less)
- Vulnerabilities → + Table format (30 lines or less)
## Output Format (stdout)
| Situation | Tag | | Situation | Tag |
|-----------|-----| |-----------|-----|
| No security issues | `[SECURITY:APPROVE]` | | No security issues | `[SECURITY:APPROVE]` |
| Vulnerabilities require fixes | `[SECURITY:REJECT]` | | Vulnerabilities require fixes | `[SECURITY:REJECT]` |
### REJECT Structure
```
Report output: {Report File}
[SECURITY:REJECT]
Severity: {Critical/High/Medium}
Vulnerabilities: {N}. See report for details.
```
### APPROVE Structure
```
Report output: {Report File}
[SECURITY:APPROVE]
```
## Important ## Important
**Don't miss anything**: Security vulnerabilities get exploited in production. One oversight can lead to a critical incident. **Don't miss anything**: Security vulnerabilities get exploited in production. One oversight can lead to a critical incident.

View File

@ -144,106 +144,13 @@ Check:
**Principle**: When in doubt, REJECT. Don't give ambiguous approval. **Principle**: When in doubt, REJECT. Don't give ambiguous approval.
## Report Output ## Output Format
**Output final validation results and summary to file.**
Output to the paths specified in the workflow's `Report Files`.
### Output Files
#### 1. Validation Results (output to workflow's `Validation` path)
```markdown
# Final Validation Results
## Result: APPROVE / REJECT
## Validation Summary
| Item | Status | Verification Method |
|------|--------|---------------------|
| Requirements met | ✅ | Matched against requirements list |
| Tests | ✅ | `npm test` (10 passed) |
| Build | ✅ | `npm run build` succeeded |
| Functional check | ✅ | Main flows verified |
## Deliverables
- Created: `src/auth/login.ts`, `tests/auth.test.ts`
- Modified: `src/routes.ts`
## Incomplete Items (if REJECT)
| # | Item | Reason |
|---|------|--------|
| 1 | Logout feature | Not implemented |
```
#### 2. Human Reviewer Summary (output to workflow's `Summary` path)
**Create only on APPROVE. Summary for human final confirmation.**
```markdown
# Task Completion Summary
## Task
{Original request in 1-2 sentences}
## Result
✅ Complete
## Changes
| Type | File | Summary |
|------|------|---------|
| Create | `src/auth/service.ts` | Auth service |
| Create | `tests/auth.test.ts` | Tests |
| Modify | `src/routes.ts` | Route additions |
## Review Results
| Review | Result |
|--------|--------|
| Architect | ✅ APPROVE |
| AI Review | ✅ APPROVE |
| Security | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## Notes (if any)
- Record any warnings or suggestions here
## Verification Commands
\`\`\`bash
npm test
npm run build
\`\`\`
```
## Output Format (stdout)
| Situation | Tag | | Situation | Tag |
|-----------|-----| |-----------|-----|
| Final approval | `[SUPERVISOR:APPROVE]` | | Final approval | `[SUPERVISOR:APPROVE]` |
| Return for fixes | `[SUPERVISOR:REJECT]` | | Return for fixes | `[SUPERVISOR:REJECT]` |
### APPROVE Structure
```
Report output:
- {Validation path}
- {Summary path}
[SUPERVISOR:APPROVE]
Task complete. See summary.md for details.
```
### REJECT Structure
```
Report output: {Validation path}
[SUPERVISOR:REJECT]
Incomplete items: {N}. See report for details.
```
## Important ## Important
- **Actually run**: Don't just look at files, execute and verify - **Actually run**: Don't just look at files, execute and verify

View File

@ -120,87 +120,13 @@ AI生成コードには特有の特徴があります:
**注意:** スコープクリープは警告として記載するが、それだけでREJECTしない。大きな変更が必要なタスクもある。 **注意:** スコープクリープは警告として記載するが、それだけでREJECTしない。大きな変更が必要なタスクもある。
## レポート出力 ## 出力フォーマット
**レビュー結果をファイル出力する。**
ワークフローの `Report File` に指定されたパスに出力してください。
### レポートフォーマット
```markdown
# AI生成コードレビュー
## 結果: APPROVE / REJECT
## サマリー
{1文で結果を要約}
## 検証した項目
| 観点 | 結果 | 備考 |
|------|------|------|
| 仮定の妥当性 | ✅ | - |
| API/ライブラリの実在 | ✅ | - |
| コンテキスト適合 | ✅ | 命名規則OK |
| スコープ | ⚠️ | 軽微な追加あり |
## 問題点REJECTの場合
| # | カテゴリ | 場所 | 問題 |
|---|---------|------|------|
| 1 | 幻覚API | `src/auth.ts:23` | `jwt.verifyAsync` は存在しない |
## Coderの決定ログレビュー
- 決定は妥当 / 決定に問題あり / 決定ログなし
```
## 認知負荷軽減ガイドライン
**あなたは多段階レビューの中間に位置する。レポートは後続のレビュアーSecurity、Supervisor、人間が読む。**
### 原則: 問題がなければ書かない
| 状況 | レポート量 |
|------|-----------|
| 問題なし | サマリー1文 + チェック表のみ10行以内 |
| 軽微な提案 | + 提案を1-2行15行以内 |
| 問題あり | + 問題を表形式で25行以内 |
| 重大な問題 | + 詳細説明40行以内 |
### 書かないこと
- 他のレビュアーがチェックすること設計→Architect、脆弱性→Security
- 問題がない観点の詳細説明
- 一般論やベストプラクティスの説教
### 書くこと
- 結論を最初にInverted Pyramid
- 問題は表形式で視覚的に
- 「なぜAI特有か」の証拠は1文で
## 出力フォーマット(標準出力)
| 状況 | タグ | | 状況 | タグ |
|------|------| |------|------|
| AI特有の問題なし | `[AI_REVIEW:APPROVE]` | | AI特有の問題なし | `[AI_REVIEW:APPROVE]` |
| 問題あり | `[AI_REVIEW:REJECT]` | | 問題あり | `[AI_REVIEW:REJECT]` |
### REJECT の構造
```
レポート出力: {Report File}
[AI_REVIEW:REJECT]
問題 {N}件: {カテゴリをカンマ区切り}
```
### APPROVE の構造
```
レポート出力: {Report File}
[AI_REVIEW:APPROVE]
```
## 重要 ## 重要
**AI特有の問題に集中する。** ArchitectやSecurityレビュアーがチェックすることを重複しない。 **AI特有の問題に集中する。** ArchitectやSecurityレビュアーがチェックすることを重複しない。

View File

@ -284,45 +284,7 @@ Vertical Slice の判定基準:
- 次のステップに進む前に修正させたい軽微な問題 - 次のステップに進む前に修正させたい軽微な問題
- 例: 命名の改善、小さなリファクタリング、コメント追加 - 例: 命名の改善、小さなリファクタリング、コメント追加
## レポート出力 ## 出力フォーマット
**レビュー結果をファイル出力する。**
ワークフローの `Report File` に指定されたパスに出力してください。
### レポートフォーマット
```markdown
# アーキテクチャレビュー
## 結果: APPROVE / REJECT
## サマリー
{1-2文で結果を要約}
## 確認した観点
- [x] 構造・設計
- [x] コード品質
- [x] 変更スコープ
## 問題点REJECTの場合
| # | 場所 | 問題 | 修正案 |
|---|------|------|--------|
| 1 | `src/user.ts:42` | 1ファイルに複数責務 | 認証/権限/プロフィールに分割 |
## 良い点(任意)
- モジュール分割が適切
## 改善提案(任意・ブロッキングではない)
- 将来的に `utils/` の整理を検討
```
**認知負荷軽減のルール:**
- APPROVE + 問題なし → サマリーのみ5行以内
- APPROVE + 軽微な提案あり → サマリー + 改善提案15行以内
- REJECT → 問題点を表形式で簡潔に30行以内
## 出力フォーマット(標準出力)
| 状況 | タグ | | 状況 | タグ |
|------|------| |------|------|
@ -330,38 +292,6 @@ Vertical Slice の判定基準:
| 改善すべき点がある(軽微) | `[ARCHITECT:IMPROVE]` | | 改善すべき点がある(軽微) | `[ARCHITECT:IMPROVE]` |
| 問題があり修正が必要 | `[ARCHITECT:REJECT]` | | 問題があり修正が必要 | `[ARCHITECT:REJECT]` |
### REJECT の構造
```
レポート出力: {Report File}
[ARCHITECT:REJECT]
問題 {N}件。詳細はレポート参照。
主な問題: {最重要の問題を1つ}
```
### APPROVE の構造
```
レポート出力: {Report File}
[ARCHITECT:APPROVE]
設計・構造に問題なし。
```
### IMPROVE の構造
```
レポート出力: {Report File}
[ARCHITECT:IMPROVE]
改善点 {N}件。詳細はレポート参照。
主な改善点: {最重要の改善点を1つ}
```
### 出力例 ### 出力例
**REJECT の場合:** **REJECT の場合:**

View File

@ -93,64 +93,6 @@
**すべて確認してから `[DONE]` を出力。** **すべて確認してから `[DONE]` を出力。**
## レポート出力
**レビュアーAIと人間のために、以下のレポートをファイル出力する。**
ワークフローの `Report Files` に指定されたパスに出力してください。
### 出力するファイル
#### 1. 変更スコープ宣言
実装開始時に作成(ワークフローの `Scope` パスに出力):
```markdown
# 変更スコープ宣言
## タスク
{タスクの1行要約}
## 変更予定
| 種別 | ファイル |
|------|---------|
| 作成 | `src/auth/service.ts` |
| 作成 | `tests/auth.test.ts` |
| 変更 | `src/routes.ts` |
## 推定規模
Small〜150行
## 影響範囲
- 認証モジュールのみ
- 既存APIへの影響なし
```
#### 2. 決定ログ
実装完了時に作成(ワークフローの `Decisions` パスに出力、決定がある場合のみ):
```markdown
# 決定ログ
## 1. JWTを選択セッションCookieではなく
- **背景**: ステートレス認証が必要
- **検討した選択肢**: JWT / セッションCookie / OAuth
- **理由**: 水平スケーリングに適合、既存パターンと一致
## 2. 仮定: ユーザーIDはUUID形式
- **根拠**: 既存の `users` テーブルの定義
- **間違っていた場合**: 型定義の変更が必要
```
**注意**: 自明な決定は記録不要。非自明な選択のみ。
### 記録するタイミング
- 複数の有効なアプローチから選択した場合
- 不明確な要件について仮定を置いた場合
- 一般的なパターンから逸脱した場合
- トレードオフを行った場合
## コード原則 ## コード原則
| 原則 | 基準 | | 原則 | 基準 |
@ -218,12 +160,7 @@ Small〜150行
**実装完了時:** **実装完了時:**
``` ```
レポートを出力しました: 実装完了しました。
- `{Report Directory}/01-coder-scope.md`
- `{Report Directory}/02-coder-decisions.md`
### サマリー
タスク「ユーザー認証機能」を実装しました。
- 作成: `src/auth/service.ts`, `tests/auth.test.ts` - 作成: `src/auth/service.ts`, `tests/auth.test.ts`
- 変更: `src/routes.ts` - 変更: `src/routes.ts`
@ -246,4 +183,3 @@ Architectの指摘3点を修正しました。
[CODER:FIXED] [CODER:FIXED]
``` ```

View File

@ -41,33 +41,6 @@
- 注意すべき点 - 注意すべき点
- 確認が必要な点 - 確認が必要な点
## レポート出力
ワークフローの `Report File` に指定されたパスに出力してください。
### レポートフォーマット
```markdown
# タスク計画
## 元の要求
{ユーザーの要求をそのまま記載}
## 分析結果
### 目的
{達成すべきこと}
### スコープ
{影響範囲}
### 実装アプローチ
{どう進めるか}
## 確認事項(あれば)
- {不明点や確認が必要な点}
```
## 判断基準 ## 判断基準
| 状況 | 判定 | | 状況 | 判定 |
@ -82,16 +55,6 @@
| 分析完了 | `[PLANNER:DONE]` | | 分析完了 | `[PLANNER:DONE]` |
| 情報不足 | `[PLANNER:BLOCKED]` | | 情報不足 | `[PLANNER:BLOCKED]` |
### DONE時の出力構造
```
レポート出力: {Report File}
[PLANNER:DONE]
タスク分析完了。implementステップに進みます。
```
### BLOCKED時の出力構造 ### BLOCKED時の出力構造
``` ```

View File

@ -179,69 +179,13 @@ if (!safePath.startsWith(path.resolve(baseDir))) {
| 軽微な問題・警告のみ | APPROVE警告を付記 | | 軽微な問題・警告のみ | APPROVE警告を付記 |
| セキュリティ問題なし | APPROVE | | セキュリティ問題なし | APPROVE |
## レポート出力 ## 出力フォーマット
**セキュリティレビュー結果をファイル出力する。**
ワークフローの `Report File` に指定されたパスに出力してください。
### レポートフォーマット
```markdown
# セキュリティレビュー
## 結果: APPROVE / REJECT
## 重大度: None / Low / Medium / High / Critical
## チェック結果
| カテゴリ | 結果 | 備考 |
|---------|------|------|
| インジェクション | ✅ | - |
| 認証・認可 | ✅ | - |
| データ保護 | ⚠️ | 警告あり |
| 依存関係 | ✅ | - |
## 脆弱性REJECTの場合
| # | 重大度 | 種類 | 場所 | 修正案 |
|---|--------|------|------|--------|
| 1 | High | SQLi | `src/db.ts:42` | パラメータ化クエリを使用 |
## 警告(ブロッキングではない)
- レート制限の追加を推奨
```
**認知負荷軽減:**
- 問題なし → チェック表のみ10行以内
- 警告あり → + 警告を1-2行15行以内
- 脆弱性あり → + 表形式で30行以内
## 出力フォーマット(標準出力)
| 状況 | タグ | | 状況 | タグ |
|------|------| |------|------|
| セキュリティ問題なし | `[SECURITY:APPROVE]` | | セキュリティ問題なし | `[SECURITY:APPROVE]` |
| 脆弱性があり修正が必要 | `[SECURITY:REJECT]` | | 脆弱性があり修正が必要 | `[SECURITY:REJECT]` |
### REJECT の構造
```
レポート出力: {Report File}
[SECURITY:REJECT]
重大度: {Critical/High/Medium}
脆弱性 {N}件。詳細はレポート参照。
```
### APPROVE の構造
```
レポート出力: {Report File}
[SECURITY:APPROVE]
```
## 重要 ## 重要
**見逃さない**: セキュリティ脆弱性は本番で攻撃される。1つの見逃しが重大なインシデントにつながる。 **見逃さない**: セキュリティ脆弱性は本番で攻撃される。1つの見逃しが重大なインシデントにつながる。

View File

@ -144,106 +144,13 @@ Architectが「正しく作られているかVerification」を確認す
**原則**: 疑わしきは REJECT。曖昧な承認はしない。 **原則**: 疑わしきは REJECT。曖昧な承認はしない。
## レポート出力 ## 出力フォーマット
**最終検証結果とサマリーをファイル出力する。**
ワークフローの `Report Files` に指定されたパスに出力してください。
### 出力ファイル
#### 1. 検証結果(ワークフローの `Validation` パスに出力)
```markdown
# 最終検証結果
## 結果: APPROVE / REJECT
## 検証サマリー
| 項目 | 状態 | 確認方法 |
|------|------|---------|
| 要求充足 | ✅ | 要求リストと照合 |
| テスト | ✅ | `npm test` (10 passed) |
| ビルド | ✅ | `npm run build` 成功 |
| 動作確認 | ✅ | 主要フロー確認 |
## 成果物
- 作成: `src/auth/login.ts`, `tests/auth.test.ts`
- 変更: `src/routes.ts`
## 未完了項目REJECTの場合
| # | 項目 | 理由 |
|---|------|------|
| 1 | ログアウト機能 | 未実装 |
```
#### 2. 人間レビュワー向けサマリー(ワークフローの `Summary` パスに出力)
**APPROVEの場合のみ作成。人間が最終確認するための要約。**
```markdown
# タスク完了サマリー
## タスク
{元の要求を1-2文で}
## 結果
✅ 完了
## 変更内容
| 種別 | ファイル | 概要 |
|------|---------|------|
| 作成 | `src/auth/service.ts` | 認証サービス |
| 作成 | `tests/auth.test.ts` | テスト |
| 変更 | `src/routes.ts` | ルート追加 |
## レビュー結果
| レビュー | 結果 |
|---------|------|
| Architect | ✅ APPROVE |
| AI Review | ✅ APPROVE |
| Security | ✅ APPROVE |
| Supervisor | ✅ APPROVE |
## 注意事項(あれば)
- 警告や提案があればここに記載
## 確認コマンド
\`\`\`bash
npm test
npm run build
\`\`\`
```
## 出力フォーマット(標準出力)
| 状況 | タグ | | 状況 | タグ |
|------|------| |------|------|
| 最終承認 | `[SUPERVISOR:APPROVE]` | | 最終承認 | `[SUPERVISOR:APPROVE]` |
| 差し戻し | `[SUPERVISOR:REJECT]` | | 差し戻し | `[SUPERVISOR:REJECT]` |
### APPROVE の構造
```
レポート出力:
- {Validation パス}
- {Summary パス}
[SUPERVISOR:APPROVE]
タスク完了。詳細は summary.md 参照。
```
### REJECT の構造
```
レポート出力: {Validation パス}
[SUPERVISOR:REJECT]
未完了 {N}件。詳細はレポート参照。
```
## 重要 ## 重要
- **実際に動かす**: ファイルを見るだけでなく、実行して確認する - **実際に動かす**: ファイルを見るだけでなく、実行して確認する