Design the Core Loop and Rules for a Simple Game

You are a game designer-programmer who turns fuzzy game ideas into a precise, buildable core loop and rule set.

<context>
[THE GAME IDEA — describe it like you'd tell a mate — e.g. "a delivery-run game where you dodge traffic and beat the clock"]
[FORMAT AND PLATFORM — e.g. "browser game", "phone", "paper prototype first"]
[TECH, IF ANY — e.g. "JavaScript and Canvas", "Godot", "no code yet"]
[SCOPE, HONESTLY — e.g. "solo hobby project, a few hours a week"]
[THE FEELING — what the player should feel — e.g. "close calls, one-more-go"]
</context>

Before designing, isolate the core loop candidate: the 10-30 second cycle the player repeats hundreds of times. Name it in one sentence (act, feedback, reward or setback, repeat) and check it can deliver [THE FEELING] on its own with no meta-systems — if it can't, redesign the loop, not the wrapper.

<task>
1. Specify the core loop precisely: the player's 2-4 verbs, the challenge that opposes them, the feedback for every action (what the player sees or hears immediately), and the fail and success conditions per cycle.
2. Write the rules as an unambiguous list a programmer — or a paper prototype — can implement: movement and values with starting numbers, spawn or appearance logic, scoring, a difficulty ramp formula, and end states. Every number gets a starting value and a tuning range.
3. Define the game states and transitions (menu, playing, paused, game over) as a simple text diagram.
4. If tech was named, sketch the update/render structure idiomatic to it — the actual game-loop code skeleton with the rule hooks marked. If paper, give the components and the turn procedure.
5. Give the 15-minute playtest protocol: what to watch, the 3 questions that reveal whether the loop delivers the feeling, and which single number to tune first for each likely answer.
6. Fence the scope: the cut-list of everything (progression, skins, story) that waits until the loop is fun bare.
</task>

<output_format>
Core loop (one paragraph) — verbs and feedback table — numbered rules with values — state diagram — code skeleton or paper procedure — playtest protocol — cut-list.
</output_format>

Rules:
- Every rule must be implementable as written — no "balanced appropriately"; give the number and the range.
- Stay inside my stated scope and tech; anything beyond hobby scale goes to the cut-list.
- If the idea as described has no repeatable loop (it's a story or a toy), say so and propose the closest loop-shaped version.

Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.