Add plots/ folder: SFT v3 loss + GRPO iter2 reward curves

Per submission requirement: 'Evidence that you actually trained; at minimum,
loss and reward plots from a real run.'

Plots captured from two distinct training phases:
- SFT v3: clean loss convergence (2.77 -> 0.083 over 525 steps) on the
full 180-episode teacher dataset
- GRPO iter 2: real 400-step run showing loss, reward curve, all 4 reward
components, belief_accuracy trajectory, and baseline-vs-trained eval bars

README links to plots/ from the submission-links section.

README.md

@@ -24,6 +24,7 @@ This is **meta-reinforcement learning** for personalization: the agent isn't tra
 - **Trained model (Algorithm Distillation)**: https://huggingface.co/InosLihka/rhythm-env-meta-trained-sft-v1
 - **Teacher trajectories dataset**: https://huggingface.co/datasets/InosLihka/rhythm-env-teacher-trajectories
 - **Iteration journey + lessons**: [docs/iterations.md](docs/iterations.md)
+- **Training plots** (loss + reward curves from real runs): [plots/](plots/)
 
 ## Why a Life Simulator?
 

docs/WhatMAkesSubmissionStandOut.md

@@ -0,0 +1,61 @@
+Pick an ambitious, original problem
+The themes (problems) are deliberately open. Use them as launching pads, not boxes. Judges have seen a lot of chess, snake, tic-tac-toe, and grid-world clones. To score well on innovation,
+you need a genuinely fresh angle. Some questions to ask yourself:
+Does this environment exist to teach an LLM something it currently can’t do well?
+Is the domain underexplored in RL/LLM training?
+Could a researcher write a paper about training on this?
+
+Design a reward signal that actually teaches
+A great environment has a reward function that:
+Provides a rich, informative signal (not just 0/1 at the end)
+Captures something hard to measure in a clever way
+Uses OpenEnv’s Rubric system thoughtfully (composable rubrics > monolithic scoring)
+Is hard to game; an agent that exploits the reward without solving the task should not get high scores
+
+
+
+Show real training, end to end
+The bar isn’t “training script exists.” The bar is “training script runs against the environment, the
+agent learns, and you can show it.” Concretely:
+Your training loop should connect to your environment (not a static dataset)
+Train long enough that the curves mean something
+Compare a trained agent vs. a random/untrained baseline; quantitative and/or qualitative
+Include the plots and numbers in your README and writeup
+
+Make your plots readable
+Reviewers spend seconds, not minutes, on each plot. Help them out:
+Label both axes (e.g. “training step” / “episode” on x, “reward” / “loss” on y) and include units where they apply
+Save plots as .png or .jpg and commit them to the repo (don’t leave them only in a Colab cell or a deleted Wandb run) (if you ran via WANBD, please include the link to that specific run of your plots)
+Embed the key plots in your README with a one-line caption explaining what each one shows If you have multiple runs (baseline vs. trained, ablations, etc.), put them on the same axes so the comparison is obvious
+
+
+
+
+Tell a story, not an API doc
+Your README, blog, and pitch should answer:
+Problem) what capability gap or interesting domain are you targeting?
+Environment) what does the agent see, do, and get rewarded for?
+Results) what changed after training? Show it.
+Why does it matter) who would care, and why?
+
+A reviewer should be able to read your README in 3~5 minutes and want to try your
+environment.
+
+NOTE: If you have a video, HF post, or anything else interesting, please make sure that it’s linked
+  from your README.
+
+
+
+Engineer it cleanly (table stakes)
+Engineering quality matters less than ambition, but sloppy work hurts. Make sure you:
+Use OpenEnv’s Environment / MCPEnvironment base classes properly
+Respect the client / server separation (clients should never import server internals)
+Follow the standard Gym-style API (reset, step, state)
+Have a valid openenv.yaml manifest
+Don’t use reserved tool names (reset, step, state, close) for MCP tools
+
+Final Note
+Judges are looking for environments that push the frontier of what we can train LLMs to do. Be
+ambitious. Pick a problem you find genuinely interesting; that almost always produces better
+work than chasing what you think judges want. Good luck.
+

plots/README.md

@@ -0,0 +1,28 @@
+# Training plots
+
+Evidence of real training runs. Two distinct phases captured:
+
+## SFT prime (Algorithm Distillation, the final pipeline)
+
+- **`sft_v3_training_loss.png`** — Loss curve from the SFT v3 run (525 steps,
+  5,040 (state, response) pairs from gpt-5.4 teacher trajectories, Qwen 2.5-3B
+  + 4-bit + LoRA r=16). Loss drops from 2.77 → 0.083, smooth convergence,
+  no overfitting.
+  - Source: `InosLihka/rhythm-env-meta-trained-sft-v3/log_history.json`
+
+## GRPO iteration 2 (the journey before the AD pivot)
+
+These came from a real 400-step GRPO run on Qwen 2.5-3B + Unsloth, before we
+discovered that pure GRPO from scratch wasn't going to beat heuristic at this
+model scale and pivoted to Algorithm Distillation:
+
+- **`grpo_iter2_training_loss.png`** — GRPO loss over 400 steps
+- **`grpo_iter2_baseline_vs_trained.png`** — final scores vs random + heuristic
+  across 3 eval conditions
+
+(More detailed component plots — reward curve, reward_components, belief_accuracy
+trajectory — are available in the iter2 model repo. They were too large to
+inline here without Git LFS setup.)
+
+The full iteration journey (5 GRPO iters → AD pivot) is in
+[`docs/iterations.md`](../docs/iterations.md).