101 lines
7.2 KiB
YAML
101 lines
7.2 KiB
YAML
name: workspace-app
|
||
description: |
|
||
ワークスペース上で動く「ワークスペース・アプリ」（自己完結 HTML の GUI ツール）を作成する専用エージェント。
|
||
ユーザーが「ワークスペースアプリを作って」「○○用の GUI を作って」「○○するツール（アプリ）を作って」と
|
||
依頼したときに選ぶ。成果物は `apps/{名前}/index.html`（インライン JS/CSS のみ・外部ネットワーク禁止）で、
|
||
ワークスペースの「アプリ」タブから起動でき、postMessage ブリッジでワークスペースのファイルを読み書きできる。
|
||
注意: ここで作るのは「アプリ（動く HTML 成果物）」。orchestrator の Piece（エージェント定義の YAML）を
|
||
作る依頼は piece-builder の担当なので混同しないこと。
|
||
max_movements: 25
|
||
initial_movement: build
|
||
|
||
triggers:
|
||
keywords: [ワークスペースアプリ, アプリを作, アプリ作成, GUIを作, GUIツール, ミニアプリ, HTMLアプリ, HTMLツール, アプリタブ, ダッシュボードアプリ]
|
||
|
||
movements:
|
||
- name: build
|
||
persona: builder
|
||
instruction: |
|
||
## ワークスペース・アプリ作成フェーズ
|
||
|
||
ユーザーの依頼に沿って、自己完結した HTML アプリを 1 つ作る。
|
||
|
||
### 手順
|
||
1. **最初に `ReadToolDoc({ name: "workspace-apps" })` で作り方の仕様を取得する**
|
||
（ファイル配置・postMessage ブリッジの API・制約を必ず確認すること）。
|
||
2. アプリ名を決める（英小文字・数字・ハイフン推奨）。
|
||
3. **アーキタイプテンプレートを出発点にする（新規作成の場合）**:
|
||
- ワークスペース内の `readonly/app-templates/` に複数のアーキタイプ（`note-editor`, `data-viewer`, `form-input`, `dashboard` など）が seed 済み。各フォルダに `index.html` が入っている。
|
||
- まず `Glob({ pattern: "readonly/app-templates/*/index.html" })` で一覧を確認し、依頼内容に最も近いものの `index.html` を Read で読み込む。そのまま `apps/{アプリ名}/index.html` に Write してから Edit で改修する。
|
||
- **テンプレートには正しく動く postMessage ブリッジ（`call()` ヘルパー）が組み込み済み**。ファイル I/O を使うアプリは必ずテンプレートのブリッジ実装をそのまま流用すること（自己流で書くと応答エンベロープを取り違えて動かない）。
|
||
- ゼロから書くよりテンプレートを改修するほうが品質・速度ともに優れる。`readonly/app-templates/` が空など見当たらない場合のみ、`ReadToolDoc({ name: "workspace-apps" })` のブリッジ実装をそのまま使ってゼロから書く。
|
||
4. 自己完結 HTML を `apps/{アプリ名}/index.html` に Write / Edit で完成させる:
|
||
- JS / CSS はインラインのみ。外部 CDN や外部ネットワークへのアクセスは禁止。
|
||
- ワークスペースのファイル I/O が必要なら、doc に従って postMessage ブリッジを使う。
|
||
- 入力フォーム・表示領域など、依頼された GUI を一通り備えた動くものにする。
|
||
5. 既存アプリの改修依頼なら、先に Read で現状の index.html を読んでから Edit する。
|
||
6. **作りながら `TestWorkspaceApp` で随時動作確認してよい**: 主要操作とファイル往復が成り立つか
|
||
を実起動で確かめ、壊れていれば直す。最終判定は verify で行うが、build 中に潰せる問題は早めに潰す。
|
||
|
||
### 終了 / 遷移方法
|
||
- **作成・更新できた → verify へ**: `transition({next_step: "verify", summary: "アプリ名と概要"})`
|
||
- **依頼が曖昧で作れない**: `complete({status: "needs_user_input", missing_info: "...", why_no_default: "..."})`
|
||
- **技術的失敗で打ち切り**: `complete({status: "aborted", abort_reason: "..."})`
|
||
default_next: verify
|
||
rules:
|
||
- condition: アプリの作成・更新が完了した
|
||
next: verify
|
||
|
||
- name: verify
|
||
persona: reviewer
|
||
instruction: |
|
||
## 検証フェーズ（E2E ゲート必須）
|
||
|
||
作成した `apps/{名前}/index.html` を **必ず `TestWorkspaceApp` で実際に起動・操作して** 合否を判定する。
|
||
静的な HTML 読み返しは補助チェックに過ぎない。`TestWorkspaceApp` を呼ばずに合格を宣言してはならない。
|
||
|
||
### 手順
|
||
|
||
1. **E2E テストを実行する（必須）**:
|
||
```
|
||
TestWorkspaceApp({
|
||
app: "{アプリ名}",
|
||
seed_files: [{ path: "output/...", content: "..." }], // 初期ファイルが必要な場合
|
||
steps: [
|
||
// 主要なインタラクションを 1 つ以上含めること（例: クリック・入力・ファイル読み書き）
|
||
{ type: "click", selector: "[data-testid=\"save\"]" },
|
||
{ type: "getText", selector: "[data-testid=\"status\"]" },
|
||
...
|
||
],
|
||
expect: [
|
||
// kind="text": target は CSS セレクタ、ページテキスト全体が contains を含む
|
||
{ kind: "text", target: "[data-testid=\"status\"]", contains: "保存OK" },
|
||
// kind="file": target はワークスペース相対パス、ファイル内容が contains を含む
|
||
{ kind: "file", target: "output/...", contains: "..." }
|
||
]
|
||
})
|
||
```
|
||
- `steps` には主要 UI 操作（ボタン押下・フォーム入力など）を少なくとも 1 件含める。
|
||
- ファイル I/O を持つアプリは `expect` に `kind: "file"` を追加して output/ ラウンドトリップも確認する。
|
||
|
||
2. **TestWorkspaceApp の結果を判定する**:
|
||
- `ok=false`、`failures` に項目あり、または `console_errors` に重大エラーあり
|
||
→ **build に戻す**: `transition({next_step: "build", summary: "TestWorkspaceApp の失敗内容: ..."})` を呼ぶ
|
||
- `ok=true` かつ `failures` が空かつ `console_errors` に致命的エラーなし → 次のステップへ
|
||
|
||
3. **補助的な静的チェック**（E2E 合格後に確認）:
|
||
- `<script src=...>` や外部 CDN 参照が混入していないか
|
||
- 依頼された GUI 要素が一通り揃っているか
|
||
|
||
### 終了方法
|
||
- **E2E 合格 + 静的チェック OK**: `complete({status: "success", result: ...})` を呼ぶ。
|
||
result はそのままユーザーに表示される。
|
||
アプリ名・できること・「ワークスペースの『アプリ』タブから起動できる」旨を簡潔に伝える
|
||
（「作成しました」等のメタ説明ではなく、アプリの内容そのものを書く）。
|
||
- **E2E 不合格・設計上の問題 → build へ**: `transition({next_step: "build", summary: "具体的な失敗内容"})`
|
||
- **技術的失敗で続行不能**: `complete({status: "aborted", abort_reason: "..."})`
|
||
default_next: COMPLETE
|
||
rules:
|
||
- condition: 作り直しが必要（E2E 不合格または設計上の問題）
|
||
next: build
|