code-reasoning-distillation

178 SFT / distillation coding samples for small language models, in one train split:

• 150 single-turn (user → assistant) reasoning-focused coding samples
• 28 multi-turn (user ↔ assistant × 2) browser-game samples

Every assistant reply starts with a <think> block that derives the solution from first principles (zero-knowledge style, no template phases), followed by a concise explanation and a complete, runnable program.

Format

Single Parquet file (code-reasoning-distillation.parquet, zstd compression), one row per sample, schema:

messages: list<struct<role: string, content: string>>

Each messages is [user, assistant] for the 150 single-turn samples and [user, assistant, user, assistant] for the 28 multi-turn games. Single-turn rows: the user turn is a coding task/brief and the assistant turn is one complete program. Multi-turn rows: the first pair builds a complete browser game, the second pair adds a feature or fixes a bug and returns the full updated file.

<think>
We need ... Let's figure out ... (first-person derivation, no section headers)
... state transitions written with real values, e.g. dq: [] -> [0] ...
... at least two explicit "if I had done X instead, here is the wrong result" fixes ...
</think>

<2-4 sentence explanation>

<complete runnable code in one fenced block>

Think-block style (zero-knowledge derivation)

The think block is written as if the author has no memorized solution and derives everything from the problem statement:

• First person, exploratory voice ("Let's figure out...", "Wait - ..."). No numbered phases, no headings, no fixed DECONSTRUCTION / ARCHITECTURE template.
• Every constant, coordinate, index, and boundary is derived from literal arithmetic on the concrete demo input, not asserted.
• Loop boundaries and off-by-one cases are tested with real numbers (first iteration, last iteration, empty input).
• State changes are spelled out as before -> after with actual values; each block contains at least six such transitions.
• At least two explicit wrong-behaviour corrections: what a plausible wrong implementation would return, and why that is wrong.
• Every variable, function, and DOM id mentioned is defined in the code that follows.
• 350-550 words, plain ASCII.

Games: 28 multi-turn game samples

Every row in the games slice is a four-message conversation that builds a playable browser game and then extends or repairs it:

user      -> build brief for a single-file HTML/CSS/JS game
assistant -> think block + explanation + complete game file
user      -> one feature request or bug report
assistant -> think block + explanation + complete updated game file

Slice	Games
Retro action	snake, tetris, pong, breakout, space-invaders, asteroids
Arcade	flappy-bird, doodle-jump, frogger, pac-man-lite, bomberman-lite
Board	chess, checkers, connect-four-ai, tic-tac-toe-ai
Puzzle/logic	sudoku, 2048, minesweeper, memory-match, lights-out, sokoban
Misc	blackjack, simon, whack-a-mole, tower-defense-lite
3D / simulation	maze-escape-3d (ray caster), solar-system-3d (software projection), stack-3d (orthographic projection)

All games are vanilla, single-file, dependency-free, and expose a small window.__game debug API (state(), start(), reset(), tick(ms), plus game actions) so the core rules can be exercised without a browser driver. Every game was loaded in Chromium with zero console errors and smoke-tested through the debug API (input, ticks, scoring, lives, persistence). Think blocks follow the same zero-knowledge style as the single-turn samples.

Composition

Slice	Count	Language	Delivery
Games	53	HTML/JS + 3D/canvas	25 single-turn games + 28 multi-turn browser games
Apps	50	HTML/JS (single file, vanilla)	timers, calculators, converters, localStorage tools
Interactive tools/viz	25	HTML/JS + Canvas + Web Audio	sort/pathfinding visualizers, Web Audio synths
Algorithms	50	Python 3 (stdlib only)	DP, parsing, graphs, heaps, with if __name__ == "__main__" demos

No external libraries, fonts, images, CDNs, or assets anywhere in the samples. localStorage access is wrapped in try/catch; preventDefault on game keys.

Loading

from datasets import load_dataset

ds = load_dataset("bunnycore/code-reasoning-distillation", split="train")
print(ds)          # Dataset({features: ['messages'], num_rows: 178})
print(ds[0]["messages"][0]["content"][:200])

Rows with exactly 2 messages are the single-turn coding tasks; rows with exactly 4 are the multi-turn browser games. Filter with ds.filter(lambda r: len(r["messages"]) == 4).

Or directly:

import pandas as pd
df = pd.read_parquet("code-reasoning-distillation.parquet")

Verification performed

Every row was machine-checked before upload:

• <think>…</think> tags present; exactly one fenced code block per assistant turn; no TODO/FIXME markers in code.
• HTML entries: all <script> blocks pass node --check; every getElementById('x') resolves to an id="x" in the same entry's markup.
• Python entries: code blocks pass ast.parse; every embedded if __name__ == "__main__": demo executes and prints the annotated expected output.
• No duplicate topics or duplicate user prompts; think blocks 350-550 words with at least six -> transitions each.

Honest limitations

• Not human-reviewed. These are machine-generated and machine-checked samples. The 28 browser games were smoke-tested in Chromium through a window.__game debug API; the other 150 entries have no browser testing — canvas/audio behavior there is traced, not observed.
• Two near-duplicate mechanics (stroop-test, color-reaction) slipped through review.
• Small sample (n=178) — a seed set to iterate on, not a training-ready corpus. Expect several percent of entries to need manual repair before training.
• Assistant code follows the stated constraints (single file, stdlib-only) and encodes one reference style; style diversity is low by construction.

License

CC-BY-4.0.