ok: 3 agents, 3 edges, <= 3 rounds · модель: claude-opus-4-8 · стоп: max_rounds=3, stop_score=8
—
{
"agents": [
{
"id": "designer",
"role": "Owns the game concept and acceptance criteria doc for a browser 'terminal' mini-game themed around running `pwd`.",
"prompt": "First read AGENTS.md in the working directory and follow its conventions. You are the game designer for a single self-contained game.html. The task is literally 'run pwd': design a tiny browser terminal game where the player types shell-like commands (at minimum `pwd`) into a fake prompt and sees output. Write a short design spec to design.md covering: (1) a simulated filesystem with a current working directory the player can change with `cd` and print with `pwd`; (2) supported commands (`pwd`, `cd <dir>`, `ls`, `help`, `clear`) and their exact expected behavior; (3) a scoring/goal loop (e.g. navigate to a randomly chosen target directory using cd, then `pwd` to win); (4) UI layout: monospace terminal panel, input line, command history, status/score line. Define measurable ACCEPTANCE CRITERIA the critic can check: `pwd` prints current directory correctly from any location; `cd` updates it (including `..` and absolute paths); invalid commands show a friendly error; a win state is reachable and announced; runs offline as one file. On revision rounds, do TARGETED Edits to design.md only for the critic's notes; do not rewrite from scratch. Output only files, no chatter.",
"tools": [
"Read",
"Write",
"Edit",
"Glob"
],
"max_turns": 30
},
{
"id": "builder",
"role": "Owns game.html: the full self-contained implementation of the pwd terminal game.",
"prompt": "First read AGENTS.md in the working directory and follow its conventions. Read design.md. Implement the entire game as a single self-contained game.html in the working directory (inline CSS + JS; any libraries via CDN only, but vanilla JS is preferred and sufficient). Build a terminal-style game: a virtual filesystem tree with a currentDir path, an input line, and command handling for `pwd`, `cd <dir>` (support `.`, `..`, absolute `/a/b`, and relative paths), `ls`, `help`, `clear`. `pwd` must always print the correct absolute path of currentDir. Include the win loop from design.md (a target directory the player must navigate to, then confirm with `pwd`), a visible status/score line, and command history rendering. Keep DOM ids and JS function names descriptive and stable (e.g. handleCommand, resolvePath, currentDir). Ensure it runs by opening the file directly with no server. On revision rounds: use Glob/Read to locate the specific section, then make TARGETED Edits to the existing game.html for the critic's notes — never rewrite the whole file. Output only file changes.",
"tools": [
"Read",
"Write",
"Edit",
"Glob"
],
"max_turns": 30
},
{
"id": "critic",
"role": "Judges game.html against the acceptance criteria and returns a JSON verdict.",
"prompt": "First read AGENTS.md in the working directory and follow its conventions. Read design.md (acceptance criteria) and game.html. Evaluate strictly against the criteria: (1) `pwd` prints the correct absolute path from the initial dir and after navigation; (2) `cd` handles `..`, absolute, and relative paths and updates state; (3) `ls`, `help`, `clear` work; (4) invalid commands produce a friendly error, not a crash; (5) a win state is reachable and announced with a status/score update; (6) the file is self-contained and runs offline. Trace the JS logic by reading it (path resolution, command dispatch) rather than assuming. Report concrete failures with the responsible function/line. Output ONLY a JSON object: {\"approved\":bool,\"score\":0-10,\"notes\":[...]}. Approve only if score >= 8 and no criterion fails. On revision rounds, re-check only that prior notes were addressed plus no regressions.",
"tools": [
"Read",
"Glob"
],
"max_turns": 30
}
],
"edges": [
{
"from": "designer",
"to": "builder",
"what": "design.md: filesystem model, command specs, win loop, acceptance criteria"
},
{
"from": "builder",
"to": "critic",
"what": "game.html implementation to be judged"
},
{
"from": "critic",
"to": "builder",
"what": "JSON verdict with targeted revision notes"
}
],
"entry": "designer",
"critic": "critic",
"stop": {
"max_rounds": 3,
"stop_score": 8
},
"conventions": [
"Deliverable is exactly one self-contained game.html in the working directory; no external assets except CDN libraries.",
"Model the filesystem as a nested-object tree; keep `currentDir` as an absolute path string and resolve via a single resolvePath() helper.",
"`pwd` must always output the correct absolute path; `cd` must support `..`, `.`, absolute, and relative paths.",
"Route all input through one handleCommand(cmd) dispatcher; unknown commands print a friendly error and never throw.",
"Keep DOM ids and core function names (handleCommand, resolvePath, currentDir) stable across revisions.",
"On revision rounds, make targeted Edits to existing files only — never rewrite game.html wholesale."
]
}# AGENTS.md — конвенции этого workspace ## Проект Средний по размеру одностраничный проект: один самодостаточный deliverable (game.html / scene.html), библиотеки только с CDN, без сборки. ## Architecture - Код внутри файла организуй ЯВНЫМИ секциями с комментариями-заголовками: CONFIG / HELPERS / BACKGROUND / ENTITIES / INPUT / GAME LOOP / HUD / WIN-LOSE. - Состояние игры — в одном объекте state (не рассыпать по глобалам). - Константы (скорости, HP, размеры) — только в GAME_CONFIG сверху, не «магией» в коде. - Каждая сущность (игрок, турель, пуля) — свой draw/update блок; не смешивать. ## Style (средний проект — умеренная чистота) - Функция может быть длинной, если делает одно связное дело; НЕ дробить на микрофункции ради «чистоты». - Выносить абстракцию только при третьем повторении (rule of three). - Осмысленные имена важнее комментариев; комментарии — только «почему», не «что». - Мёртвый код удалять сразу (неиспользуемые конфиги/функции не оставлять). ## Boundaries - Deliverable — ОДИН файл; не создавать соседние .js/.css. - Никогда не переписывать файл целиком на ревизиях — только точечные Edit. - Не менять чужую секцию без необходимости: правишь физику — не трогай отрисовку. ## Workflow - Перед работой прочитай этот файл и текущий deliverable (если существует). - Прочитай lessons.md и snippets.md (общая память прошлых прогонов): не повторяй описанные там грабли, переиспользуй проверенные приёмы. - После правки убедись, что все объявленные в GAME_CONFIG сущности реально используются. ## Task-specific - Deliverable is exactly one self-contained game.html in the working directory; no external assets except CDN libraries. - Model the filesystem as a nested-object tree; keep `currentDir` as an absolute path string and resolve via a single resolvePath() helper. - `pwd` must always output the correct absolute path; `cd` must support `..`, `.`, absolute, and relative paths. - Route all input through one handleCommand(cmd) dispatcher; unknown commands print a friendly error and never throw. - Keep DOM ids and core function names (handleCommand, resolvePath, currentDir) stable across revisions. - On revision rounds, make targeted Edits to existing files only — never rewrite game.html wholesale.
# lessons.md — общая память между прогонами - [run #13] When a spec explicitly overrides the reference (e.g. 'draw in canonical upright pose' vs a kneeling reference), judge the sprite against the spec's palette/shape checklist, not a pixel match to the reference photo — and verify the exact hex codes are wired into a single color table rather than scatt - [run #11] When a runtime probe and a separate render-error log disagree on 'zero console errors', treat it as an unresolved signal and localize the throw (which frame/state) before approving, rather than deferring entirely to the cleaner artifact. - [run #11] When two artifacts disagree on 'zero console errors', compare file mtimes first — a stale error log that predates the latest source edit is not evidence of a live bug; confirm with the freshest post-edit probe and localize that every throwing path is guarded. - [run #11] When judging animation claims, trust ordered play-session frames over single-tick probes — a cold one-step movement/animation probe can read 'static/unmoved' purely from insufficient velocity build-up in its sampling window, while sequential frames reveal the real motion. - [run #11] A cold runtime probe that starts on screen 1 cannot prove a state-change fix (like scoring) that only triggers on enemy death — verify such fixes by tracing the full code path end-to-end rather than expecting the probe's static snapshot to show the change. - [run #11] Trust captured play-session frames over single-tick cold probes for motion/inertia claims — a one-frame position delta can read as 'not moving' under friction while the real gait is working. - [run #13] When a generic play-session harness probes for platformer motion (walk cycle, muzzle flash, jump), first confirm the game's actual genre from the source — penalizing a top-down free-movement game for lacking leg-animation frames would be a false negative. - [run #15] Match the evaluation harness to the artifact type: generic sprite/animation probes are noise for a text-based game and must not override direct spec-tracing. - [run #12] Copying the palette spec's hex table verbatim into a single PAL constant (single source of truth) makes visual-fidelity criteria trivially verifiable and eliminates drift between spec and code. - [run #13] When a generic play-session probe assumes a platformer (walk/fire/jump frames), judge the deliverable against the actual stated acceptance criteria and the game's real control scheme rather than penalizing absent mechanics the design never claimed. - [run #15] Runtime probe/session harness output can be templated for a different game genre (e.g. Phaser animation frames); always reconcile probe artifacts against the actual deliverable type before treating them as ground-truth failures. - [run #10] Expose runtime hooks under the conventional names external probes expect (window.game / window.gameScene), not just a bespoke namespace, so headless verification can attach without false negatives. - [run #15] When probe/animation harness data targets a different game genre than the actual deliverable, judge strictly against the written acceptance criteria and trace the real code rather than letting mismatched 'ground truth' artifacts drive the verdict. - [run #15] Judge a deliverable against its own design spec, not the evaluation harness's assumptions: a generic probe (e.g. one expecting a Phaser scene/animation frames) can produce false negatives for a correctly-built game of a different genre.
пока пусто