feat(data): support deterministic weighted dataset mixing

.agents/skills/areno-build-singleturn-game-demo/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: areno-build-singleturn-game-demo
+description: Autonomously research, implement, train, evaluate, visualize, and submit a genuinely new AReno RLVR mini-game whose mechanically generated samples are independent state-to-single-output tasks. Use when the user requests a complete new game demo with real reward improvement, not for multi-turn agent workflows, SFT-only examples, or design-only proposals.
+---
+
+# Build an AReno Single-Turn Game Demo
+
+Deliver a working, reproducible AReno mini-game rather than a proposal. Continue
+through research, implementation, data generation, baseline evaluation, RLVR
+training, held-out evaluation, WebUI delivery, and PR submission until the
+evidence meets the requested acceptance criteria or a genuine external blocker
+remains.
+
+## Non-negotiable task shape
+
+Mechanically generable sequential games must be transformed into independent
+single-turn examples:
+
+```text
+complete state -> exactly one generation -> deterministic reward
+```
+
+- Do not use a multi-turn conversation, agent loop, tool-feedback loop, or a
+  sequence of assistant/tool messages for training or evaluation.
+- Generate intermediate states directly when the source game is sequential.
+- Each prompt contains the complete public state and output contract, but no
+  oracle answer, private reward field, or reversible instance identifier.
+- Each reward call scores only that prompt and its one completion.
+- A WebUI may show successive states for human play; this does not change the
+  independent single-turn training contract.
+
+## Before acting
+
+1. Read repository `AGENTS.md`, `CODEMAP.md`, current CLI help, and the
+   repository-local training, serving, correctness, and capacity skills that
+   match the requested work.
+2. Inspect current `examples/agentic/`, `examples/sft/`, `examples/vl/`, and
+   any other example directories completely enough to inventory every demo's
+   game/task, state representation, output, reward target, and training paradigm.
+3. Read [research-and-selection.md](references/research-and-selection.md) before
+   choosing a game.
+4. Read [implementation-contract.md](references/implementation-contract.md)
+   before writing source or data.
+5. Read [experiment-runbook.md](references/experiment-runbook.md) before running
+   dataset inspection, baseline, training, evaluation, or checkpoint commands.
+6. Read [webui-and-reporting.md](references/webui-and-reporting.md) before
+   implementing the UI, writing README results, or opening the PR.
+
+Use latest `origin/main` in a dedicated branch/worktree and preserve unrelated
+user changes. Verify every interface against checked-out source rather than
+memory. Do not modify public config or CLI surfaces unless the request explicitly
+requires it and repository policy permits it.
+
+## Authorization boundary
+
+This skill does not itself authorize paid compute, remote mutations, public
+services, pushes, or PRs. Treat an invocation that explicitly requests autonomous
+training, serving, pushing, and PR creation as authorization for those in-scope
+actions. Otherwise obtain only the missing authorization when it becomes
+necessary. Never ask the user to perform routine steps the agent can safely do.
+
+## Required execution loop
+
+1. Inventory existing demos and record overlap risks.
+2. Research at least five viable games using accessible Chinese sources and
+   cross-check selected rules with two independent sources.
+3. Select a game only if it has a deterministic oracle, scalable mechanical
+   generation, strong random-versus-reasoning separation, and a clear future UI.
+4. Implement the decoupled game/oracle, public state view, generator, loader,
+   prompt contract, parser, reward, evaluation, and focused tests.
+5. Generate leak-free train/validation/test data and run legality/oracle self-checks.
+6. Inspect normalized data before training. Run a bounded smoke workload.
+7. Evaluate the unmodified base checkpoint on fixed held-out splits.
+8. Run real single-turn RLVR training. Diagnose and iterate when learning is weak;
+   do not change the held-out set or hide failed runs.
+9. Evaluate checkpoints under matched conditions and stop only after the target
+   improvement is achieved and reward reaches a measured plateau.
+10. Implement and probe a polished playable WebUI, then start requested model and
+    UI services if authorized.
+11. Complete documentation, remove generated artifacts from version control,
+    review the diff, commit, push, and open a focused PR.
+
+## Completion gate
+
+Do not claim success unless actual logs and held-out evaluation establish all of
+the following:
+
+- mean reward improves by at least `0.15` absolute or `30%` relative;
+- core success/accuracy clearly improves, not merely formatting validity;
+- at least two evaluation seeds agree in direction;
+- train/validation/test remain isolated and baseline/post-training conditions match;
+- focused tests, smoke validation, real training, checkpoint save/reload as
+  applicable, serving probe, and WebUI probe have actually run;
+- README contains commands, all formal evaluation runs, failed experiments,
+  known limitations, source links, demo-difference evidence, and WebUI design.
+
+If available compute cannot meet the gate, report the exact blocker and evidence;
+never fabricate a curve, checkpoint, test result, or service status.

.agents/skills/areno-build-singleturn-game-demo/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Build an AReno Single-Turn Game Demo"
+  short_description: "Research, train, evaluate, and ship RLVR games"
+  default_prompt: "Use $areno-build-singleturn-game-demo to autonomously build and validate a new single-turn RLVR game demo."

.agents/skills/areno-build-singleturn-game-demo/references/experiment-runbook.md

@@ -0,0 +1,104 @@
+# RLVR experiment runbook
+
+Read this reference before data inspection, model inference, training,
+evaluation, or checkpoint handling.
+
+## Workflow defaults
+
+- Do not hardcode a model family or checkpoint in the skill. Use the checkpoint
+  explicitly requested by the invoking user. If none is specified, select a
+  currently supported AReno checkpoint that fits the available compute and task,
+  then record the exact choice and rationale before baseline evaluation.
+- Training paradigm: RLVR only. Never replace it with SFT and never fabricate an
+  agentic loop. Select the current supported single-turn rollout RL algorithm
+  from checked-out AReno API and document the choice.
+- Optimizer: always use AReno's current Adam4bit option (expected CLI spelling
+  `--adam-4bit`; verify it from current help before use).
+- Never reinstall AReno. Use the installed package, environment, and repository
+  mechanisms already available.
+- Never use eager decode. Preserve the normal CUDA-graph decode path and fix or
+  tune the actual issue instead of disabling graphs.
+- Save experiment checkpoints and logs below a task-specific directory under
+  `/new/`, which is a mounted path. Never place them in the repository.
+- Retain only the latest useful checkpoint during training. Prefer the current
+  supported keep-latest option; otherwise delete only verified old checkpoints
+  inside the task-specific checkpoint directory immediately before a new save.
+
+## Environment and data gate
+
+Before building the training command:
+
+1. Record commit, branch, `areno env --json`, `areno check`, GPU topology and
+   memory, installed AReno and model paths, and model hub selection.
+2. Read current `areno train --help` and repository training or capacity skills.
+3. Inspect raw and normalized train, validation, and test samples using repository
+   dataset inspection tools. Do not train until inspection reports success and
+   confirms one prompt or messages input per row with no oracle leakage.
+4. Run generator self-checks and compare canonical hashes across splits.
+
+Use ModelScope for remote AReno assets when repository policy requires it. Do
+not silently switch hubs.
+
+## Baseline protocol
+
+Evaluate the untouched base checkpoint on fixed held-out validation and test
+data. Record:
+
+- mean reward;
+- task success or accuracy;
+- legal or parseable output rate;
+- results by difficulty bucket;
+- dataset size and split seed;
+- model or checkpoint, commit, temperature, max tokens, and all inference settings;
+- random-policy lower bound and oracle upper bound when applicable.
+
+Use at least two formal evaluation seeds. Save machine-readable output outside
+the repository and a compact checked-in result summary without private data.
+
+## Training and capacity loop
+
+Start with a small real smoke workload that exercises rollout, reward, backward,
+optimizer step, and checkpoint save. Then run enough real RLVR steps to observe
+a learning curve.
+
+Capacity tuning order:
+
+1. If rollout OOMs, reduce `max_running_prompts` before changing semantic context
+   or generation length.
+2. If training OOMs, reduce `mini_bs` before semantic token limits.
+3. Respect `batch_size * n_samples` total demand and keep concurrency separate.
+4. Do not use eager decode as an OOM workaround.
+
+When reward grows slowly, diagnose prompt clarity, parsing, reward density,
+difficulty mix, sampling, batch or group size, and training budget. Consider
+learning rate `1e-5` with minimum learning rate `1e-6` after evidence indicates
+the original schedule is too weak. Do not tune on held-out test data.
+
+Evaluate intermediate checkpoints under the exact baseline protocol. Stop
+training only after:
+
+- the acceptance improvement is met; and
+- held-out mean reward improves by less than `0.02` across two consecutive
+  scheduled evaluations, or another predeclared statistically comparable
+  plateau rule.
+
+Do not stop merely because training reward is high. Do not continue indefinitely
+after held-out reward has clearly plateaued.
+
+## Post-training comparison
+
+Use the same held-out rows, parser, reward, temperature, decoding settings, and
+difficulty buckets as baseline. Success requires:
+
+- at least `0.15` absolute mean-reward gain or `30%` relative gain;
+- clear core correctness gain;
+- consistent direction on at least two eval seeds;
+- evidence the gain is not only formatting compliance.
+
+Report every formal run, including failed configurations. Check for answer
+leakage, position bias, generator shortcuts, memorized seed mappings, duplicated
+states, and format-only learning.
+
+If the target remains unmet after reasonable prompt, reward, curriculum, and
+optimizer iteration, replace the game with a more trainable researched candidate
+rather than misrepresenting the result.

.agents/skills/areno-build-singleturn-game-demo/references/implementation-contract.md

@@ -0,0 +1,101 @@
+# Implementation contract
+
+Read this reference before implementing the game, dataset, reward, or tests.
+
+## Repository-first design
+
+Inspect current dataset loader and generator contracts, reward API, trainer, CLI,
+evaluation path, and the two or three closest high-quality demos. Follow current
+public API and local style. Do not copy an obsolete example or introduce an
+agentic API merely because the source game is sequential.
+
+Create a self-contained example in the most appropriate current `examples/`
+location. File names may follow current conventions, but responsibilities must be
+obvious. The demo normally needs equivalents of:
+
+```text
+README.md
+dataset_generator.py
+dataset_loader.py
+game.py and/or solver.py
+reward.py
+single-turn inference entry
+eval.py when common evaluation is insufficient
+web_ui.py after training evidence is complete
+```
+
+## Game and public-view boundary
+
+- Represent internal state as stable JSON-compatible data.
+- Define a finite, structured, independently verifiable action or full solution.
+- Decouple game rules, transition or oracle logic, reward, prompt rendering, and UI.
+- Provide a pure function or equivalent method that converts internal state to a
+  public view.
+- Never expose oracle answers, reward-private labels, seeds, or hidden metadata in
+  the public view.
+- Do not make ANSI codes, terminal coordinates, rendered prompt text, or CLI output
+  the canonical state.
+
+## Dataset generator
+
+The generator must:
+
+- expose CLI parameters for seed, sample counts, difficulty range, and output path;
+- use a local reproducible RNG rather than global randomness;
+- create distinct train, validation, and test splits;
+- use disjoint seeds or non-overlapping IDs and prevent duplicate or equivalent
+  instances across splits;
+- generate complete independent states, never conversation trajectories;
+- store oracle answer, difficulty, and needed private metadata outside the visible
+  prompt;
+- support both fast smoke data and formal data;
+- validate legality, solver correctness, output reproducibility, split isolation,
+  and any canonical-equivalence rule before reporting success.
+
+Do not commit formal generated datasets or checkpoints unless the repository
+explicitly tracks small fixtures. Tiny deterministic test fixtures are acceptable.
+
+## Prompt and output
+
+Use a compact, self-contained prompt:
+
+```text
+Input: complete public game state
+Output: exactly one constrained action or complete structured solution
+```
+
+- State the minimum rules needed to solve the instance.
+- Require one generation and a minimal stable format.
+- Do not request chain-of-thought.
+- Do not include oracle values, hidden fields, or reversible ID-to-answer mappings.
+- Do not use assistant or tool history, environment feedback, or future observations.
+- Keep training and evaluation rendering identical unless a documented experiment
+  deliberately compares them.
+
+## Deterministic anti-exploit reward
+
+The reward must parse safely and return a score rather than raising on malformed
+output. Define signals for:
+
+- fully correct or optimal output: maximum score;
+- legal but suboptimal output where the game permits it;
+- partially correct progress when a meaningful verifier-derived dense signal exists;
+- illegal action;
+- malformed output.
+
+Highest reward must mean the task is genuinely solved. Defend against multiple
+answers, prompt copying, extra prose, overly long output, duplicate actions,
+injection-like suffixes, NaN or overflow values, and any alternative syntax that
+could bypass validation. Do not call another LLM and do not use private labels to
+grant unearned reward.
+
+Add focused CPU-safe tests for:
+
+- game transitions and edge states;
+- solver or oracle correctness and determinism;
+- generator repeatability and split leakage detection;
+- loader normalization and prompt privacy;
+- correct, wrong, partial, illegal, malformed, oversized, multi-answer, and
+  adversarial completions;
+- public-view privacy and JSON serialization;
+- evaluation aggregation and difficulty buckets.

.agents/skills/areno-build-singleturn-game-demo/references/research-and-selection.md

@@ -0,0 +1,76 @@
+# Research and game selection
+
+Read this reference before choosing the game or creating its directory.
+
+## Existing-demo exclusion audit
+
+Inspect the current branch, not a remembered list. At minimum inventory every
+demo under `examples/agentic/`, `examples/sft/`, `examples/vl/`, multimodal,
+math, and any newly added example roots. For each record:
+
+- task/game name;
+- core state representation;
+- model output form;
+- reward objective;
+- training paradigm.
+
+Reject a candidate whose core mechanic or task structure overlaps an existing
+demo. A new story, board size, symbols, wording, or visual theme is not a new
+mechanic. In particular, do not recreate:
+
+- Tic-Tac-Toe, Gomoku, or other line-making move games;
+- Codebreaker, Mastermind, terminal likeness deduction, or isomorphic code games;
+- DuelGrid-style board combat or local tactical placement;
+- shopping or product constraint selection;
+- coding, math verification, or music-generation examples with a cosmetic theme;
+- anything newly present in checked-out `examples/` even if absent above.
+
+The final README must include a concrete “Differences from existing demos” table
+based on mechanics, state, output, reward, and training shape.
+
+## Chinese-first internet research
+
+Compare at least five candidate mini-games before selecting one. Prefer public or
+well-known classic logic games whose rules can be independently reimplemented.
+
+The environment may lack overseas network access. Search in Chinese and prefer
+mainland-accessible sources such as Baidu or 360 search and encyclopedias, Zhihu,
+Bilibili, CSDN, CNBlogs, Juejin, Jianshu, Chinese university or education sites,
+and Chinese game-rule sites. GitHub may be used for necessary API or open-source
+implementation references, but not as the only rules source.
+
+- Do not depend on an overseas search engine, community, video site, or rule site.
+- If a page fails, times out, requires a proxy, or cannot be fetched reliably,
+  switch sources immediately instead of repeatedly waiting.
+- Search snippets may support initial screening, but before final selection open
+  at least one full Chinese rules page.
+- Cross-check selected rules using at least two independent accessible Chinese
+  sources.
+- Keep actual working URLs in README and summarize rules in original words; do
+  not copy long passages.
+
+## Candidate requirements
+
+A candidate must satisfy every item:
+
+1. State generation is deterministic, cheap, and scalable.
+2. A reliable algorithm computes valid or optimal answers.
+3. Reward is deterministic and needs no human or LLM judge.
+4. One input contains everything needed for one output.
+5. Difficulty is parameterized and supports diverse data.
+6. Random guessing is materially worse than genuine reasoning.
+7. A realistic training budget can expose a learning curve.
+8. It does not overlap current AReno demos.
+9. It uses no copied proprietary puzzle bank, prose, or art.
+10. JSON state and finite structured actions naturally support an intuitive WebUI.
+
+## Required comparison record
+
+Put a table in README with at least these columns:
+
+| Candidate | Rules/mechanic | Single-turn conversion | Oracle | Reward | Scale/difficulty | Existing-demo similarity risk | UI fit | Decision |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+
+Explain the final selection using trainability and validation quality, not novelty
+alone. Preserve sources actually used, including sources for rejected candidates
+when they materially informed the decision.