ok: 4 agents, 4 edges, <= 3 rounds · модель: claude-opus-4-8 · стоп: max_rounds=3, stop_score=8
—
{
"conventions": [
"Deliver a single self-contained game.html; all code (HTML/CSS/JS) inline, libraries only via CDN.",
"Game has exactly three screens (turret, drone, robot) connected by teleports; collecting shards is the win/progress objective.",
"Draw the astronaut to match reference.png: same palette, helmet shape, and suit details; centralize astronaut drawing in one function drawAstronaut(ctx,x,y).",
"Use camelCase for JS identifiers; keep screen logic in a screens[] array and a single game state object named state.",
"On revision rounds do TARGETED Edits to existing game.html sections; never rewrite the whole file.",
"Keep gameplay invariants: player never falls through floor, teleports are bidirectional, shard count persists across screens."
],
"agents": [
{
"id": "reference_analyst",
"role": "Owns the astronaut visual spec extracted from reference.png",
"prompt": "First read AGENTS.md in the working directory and follow its conventions. You analyze reference.png to produce a precise visual specification for the astronaut/cosmonaut so another agent can draw it on an HTML canvas. Use Read to open reference.png (it is an image). Extract: exact color palette as hex codes (helmet, visor, suit body, gloves, boots, backpack, accent/trim, shadows), the helmet shape (round/oval/dome, proportions), and distinctive suit details (chest panel, tubes, patches, joint lines, antenna). Write a file astronaut_spec.md containing: (1) a labeled palette table with hex values, (2) a bullet list of shape/proportion rules, (3) a step-by-step draw recipe describing shapes and layer order suitable for canvas 2D primitives (arcs, rects, paths), sized for roughly a 32-48px tall sprite. Be concrete and unambiguous. On revision rounds, read critic notes and do TARGETED Edits to astronaut_spec.md only for the points raised; do not rewrite unrelated sections. Do not write game.html.",
"tools": [
"Read",
"Write",
"Edit",
"Glob"
],
"max_turns": 30
},
{
"id": "game_engineer",
"role": "Owns game.html: three screens, turret/drone/robot, teleports, shards mechanics",
"prompt": "First read AGENTS.md in the working directory and follow its conventions. You build and maintain the single deliverable game.html: a self-contained HTML5 canvas game with exactly three screens featuring a turret screen, a drone screen, and a robot screen, connected by teleports, where the player collects shards (осколки). Reuse the prior game's structure if present. Requirements: keyboard controls, a persistent state object holding shard count across screens, bidirectional teleports between screens, working win/progress condition based on shards, no falling through floors. Implement a single function drawAstronaut(ctx,x,y) that renders the player exactly per astronaut_spec.md (read it before coding the sprite): same palette hex values, helmet shape, and suit details. Keep all HTML/CSS/JS inline; CDN libraries allowed but prefer vanilla. On revision rounds, use Glob/Read to locate the specific sections and make TARGETED Edits to game.html only for the issues raised in critic notes; never rewrite the whole file. Ensure the file runs by opening directly in a browser.",
"tools": [
"Read",
"Write",
"Edit",
"Glob"
],
"max_turns": 30
},
{
"id": "art_integrator",
"role": "Owns fidelity of the in-game astronaut vs reference.png",
"prompt": "First read AGENTS.md in the working directory and follow its conventions. You verify and refine the astronaut's appearance inside game.html against astronaut_spec.md and reference.png. Read reference.png, astronaut_spec.md, and the drawAstronaut function in game.html. Compare palette hex codes, helmet shape/proportions, and suit details (panel, tubes, backpack, trim). Where the drawing diverges, make TARGETED Edits to the drawAstronaut function (and only related sprite code) in game.html to match the reference precisely — correct colors, shapes, and layering. Do not alter gameplay logic. Use Glob/Read to find the exact lines. On revision rounds, address only the astronaut-fidelity points in the critic notes with targeted Edits; never rewrite the file. Keep the file self-contained and runnable.",
"tools": [
"Read",
"Edit",
"Glob"
],
"max_turns": 30
},
{
"id": "critic",
"role": "Judges game.html against acceptance criteria and astronaut fidelity",
"prompt": "First read AGENTS.md in the working directory and follow its conventions. You are the critic. Evaluate game.html against the acceptance criteria: (1) exactly three screens with a turret, a drone, and a robot; (2) working teleports connecting screens; (3) collectible shards (осколки) with a count persisting across screens; (4) the astronaut visually matches reference.png — same palette (compare hex codes), same helmet shape, same suit details — verify by reading reference.png, astronaut_spec.md, and the drawAstronaut function in game.html; (5) the file is a single self-contained runnable game.html. Read the relevant files and code sections. Output ONLY a JSON object: {\"approved\":bool,\"score\":0-10,\"notes\":[...]}. Set approved true only when score>=8 and all criteria pass. In notes, give specific, actionable, section-referenced feedback (e.g., exact hex mismatches, missing teleport, wrong helmet shape) so agents can make targeted Edits. Do not edit any files.",
"tools": [
"Read",
"Glob"
],
"max_turns": 30
}
],
"edges": [
{
"from": "reference_analyst",
"to": "game_engineer",
"what": "astronaut_spec.md: palette hex, helmet shape, suit details, canvas draw recipe"
},
{
"from": "game_engineer",
"to": "art_integrator",
"what": "game.html with initial drawAstronaut and three-screen game logic"
},
{
"from": "art_integrator",
"to": "critic",
"what": "game.html with astronaut refined to match reference.png"
},
{
"from": "critic",
"to": "reference_analyst",
"what": "JSON verdict + notes for targeted revisions"
}
],
"entry": "reference_analyst",
"critic": "critic",
"stop": {
"max_rounds": 3,
"stop_score": 8
}
}# 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 - Deliver a single self-contained game.html; all code (HTML/CSS/JS) inline, libraries only via CDN. - Game has exactly three screens (turret, drone, robot) connected by teleports; collecting shards is the win/progress objective. - Draw the astronaut to match reference.png: same palette, helmet shape, and suit details; centralize astronaut drawing in one function drawAstronaut(ctx,x,y). - Use camelCase for JS identifiers; keep screen logic in a screens[] array and a single game state object named state. - On revision rounds do TARGETED Edits to existing game.html sections; never rewrite the whole file. - Keep gameplay invariants: player never falls through floor, teleports are bidirectional, shard count persists across screens.
# 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.
пока пусто