The team only - do NOT debate anything and do NOT build the game yet.
Those are the next two tasks.

You are about to ship a small brick-breaker for the browser: a paddle,
a ball, a wall of bricks, three lives. One question is open, and your
team of agents will settle it in the next task:

Which one twist makes this brick-breaker worth playing twice, and
can it be built, tested and shown working in about fifteen minutes?

Build the team that will argue it out. Commit it to the project, where
your coding agent loads subagents and skills from.

Subagents, at least three, each with its own brief:

1. Proposers that argue from different corners - for example the
   player's fun, the cost of building it, the risk of it breaking.
   Each commits to one answer and defends it.
2. A griller whose only job is to attack a proposal: the assumption
   it rests on, the case that breaks it, the cost nobody counted. It
   proposes nothing of its own and does not concede to be polite.
3. A referee that picks a winner by a stated rule, not by summing up
   the conversation.

Skills, at least two:

1. One that runs the whole debate from a question to a decision.
2. One that grills a single idea on its own.

Scenarios:

Scenario: Roles are different
When two subagent briefs are read side by side
Then they differ in what the agent argues for, what it receives,
what it must return and what it must not do

Scenario: The debate has a shape
When a stranger reads the debate skill
Then they know who speaks in what order, what runs in parallel,
what each round is handed, and when the debate stops

Scenario: Proposals are independent
When the proposers write their first answers
Then none of them has seen another proposer's answer

Scenario: Claims get checked
When a proposal survives the grilling
Then the skill says how it is validated with evidence - a quick
experiment, a worked example with numbers, a test - and that an
unchecked claim does not count

Scenario: The argument is kept
When the debate ends
Then the skill says where the proposals, the attacks, the
validation results and the decision are written down

Keep it sharp. Three or four precise roles and two short skills beat a
framework. A judge reads every brief in full and scores whether this
team, as written, would produce a real argument and a decision.

When you are done, write .ololo/brick-debate-team-done.md with a short
description of the team you assembled (at least 10 words).

The debate only - do NOT build the game yet, that is the next task.
Quick throwaway experiments that settle an argument are welcome.

Put your team to work on the open question:

Which one twist makes this brick-breaker worth playing twice, and
can it be built, tested and shown working in about fifteen minutes?

What is already decided and not up for debate:

the wall	5 rows of 10 bricks
points	50, 40, 30, 20, 10 per brick, top row to bottom
lives	3
the paddle	steers the ball by where the ball lands on it

A twist is one mechanic on top of these rules: something the player
does, sees or has to think about that a plain brick-breaker lacks. It
must not replace the rules above.

Run the debate with your subagents and keep the record in docs/debate/.
The decision goes in docs/debate/decision.md.

Scenarios:

Scenario: Rival proposals
When the proposers have spoken
Then the record holds at least three twists that differ in kind
And each says what the player does, what changes on screen, and
what it costs to build

Scenario: Every proposal is grilled
When a proposal is on the table
Then the record holds the griller's attacks on that proposal
And the proposer's answer to each: defended, changed, or dropped

Scenario: The argument changes something
When the grilling is over
Then at least one proposal has been changed, narrowed, merged or
dropped, and the record says which attack did it

Scenario: Survivors are validated
When a proposal is still standing
Then it is checked with evidence a reader can re-check: an
experiment that ran, a worked example with numbers, a test
And the evidence is in the project, next to the record
And an opinion that it "should work" does not count

Scenario: The decision
When the referee has ruled
Then docs/debate/decision.md names one winning twist and its rules
And says by which criteria it won and why each rival lost
And keeps the strongest objection to the winner, with how the
build will deal with it
And says what is in scope, what is out, and how you will know it
works

A judge reads the whole record and follows every pointer in it. A tidy
summary written after the fact cannot prove a debate happened, so keep
the proposals and the attacks themselves, not only the conclusion.

When you are done, write .ololo/brick-debate-debate-done.md with a
short description of what was decided and why (at least 10 words).

Build the brick-breaker, with the twist your team chose in
docs/debate/decision.md. The debate is closed: build what was decided.
You decide when it is done; a judge panel scores the result: how it
plays, whether it is the game the decision describes, the code craft,
and how it looks in a browser.

The fixed rules:

the wall	5 rows of 10 bricks
points	50, 40, 30, 20, 10 per brick, top row to bottom
lives	3

Scenarios:

Scenario: Serving the ball
When a game or a new life starts
Then the ball rests on the paddle and follows it
And it flies only when the player launches it

Scenario: Bouncing
When the ball meets a side wall, the ceiling or the paddle
Then it bounces back into play
And where it lands on the paddle steers it: nearer an edge, a
flatter angle towards that side

Scenario: Breaking a brick
When the ball hits a brick in the top row
Then the brick disappears, the ball bounces, and the score rises
by 50
When the ball hits a brick in the bottom row
Then the score rises by 10

Scenario: Losing a ball
When the ball falls past the paddle
Then one life is lost and the ball is served again from the paddle
And the bricks already broken stay broken

Scenario: Game over
When the third life is lost
Then the game says it is over, shows the final score, and the ball
stops

Scenario: Clearing the wall
When the last brick is broken
Then the game says the player won and shows the final score

Scenario: Playing again
When a game has ended
Then one control starts a fresh game: full wall, 3 lives, score 0

Scenario: The twist
When the player meets the mechanic chosen in the decision
Then it behaves by the rules the decision wrote down
And the game tells a first-time player, on screen, what the twist
is and how to use it

Scenario: The decision and the game agree
When the build has to depart from the decision
Then docs/debate/decision.md gains a dated note saying what
changed and why, instead of the game quietly differing from it

The paddle answers both the keyboard and a pointer. Everything else is
yours: colours, sound, a pause, a high score. Keep the rules of the
game apart from the drawing, so they can be tested without a browser.
Structure and duplication are part of the score.

You have a team: use it. Independent pieces can be built side by side,
and a second pair of eyes that did not write the code catches what the
author will not.

Play is a living flow. The judges verify it from a screencast of the
real game in motion, and may ask for one even after the session ends,
so keep the game runnable.

Before the first line of game code, write an AGENTS.md (or README.md)
documenting the project: the stack you chose, how the code is laid
out, and the commands the platform keeps in session memory - a run:
line with the command that runs the game and a test: line with the
command that runs its tests. The done-check requires both lines.

When a session tracks code health, every check scores it as one composite:
duplication, complexity and dead code in the code you commit, plus your
tests (the share failing) and their coverage once ololo can run them. So
name both commands: a test: line that runs the suite and a coverage:
line that runs it with coverage measured, in AGENTS.md or README.md (or
test and coverage scripts in package.json). The task's health bonus is
paid on that score.

When you are done, write .ololo/brick-debate-build-done.md with a short
description of the implemented solution (at least 10 words).