[arjunjaggi34]

Closes #294

What this does

Developer Mode becomes RL Studio (the /api/dev/* prefix is kept). Beyond pretraining, RL Studio now records a work log of answers and the feedback a person gives them, builds a dataset from that log, and runs a fine-tune round (LoRA / SFT / DPO through mlx-lm) on it.

The feedback-signal rule (ADR 0063) — the heart of this

The signal is the person's or code's, never the model grading itself:

• Thumbs up/down and "better answer" controls under each answer. A click records a work-log entry and the feedback on it; nothing asks a model which answer was better.
• A new rl_work_log table in the session store holds the prompt, the verbatim answer, tool calls with code-derived status, and the feedback. It is never read as evidence — not by recall::index_one, the memory block, titling or branching. A store test pins that the recorder writes no messages rows, and it clears with the conversations (state.rs).
• zorp_agent::rl_dataset::build turns the log into an SFT set and a preference set in code. A thumbs-down with no edit produces nothing, because it says the answer was wrong, not what the right one was — inventing one would be the model-authored signal the rule forbids.

Fine-tune plumbing

• FineTuneJobConfig; the supervisor's start_finetune, sharing one monitored-launch path with pretraining; mlx_finetune.py, which reports the dataset and example count in its init event (the same "what did this train on" metric) and refuses a run with no data.
• Routes /api/dev/worklog*, /api/dev/dataset/preview, /api/dev/finetune/start behind the train feature. A Fine-tune tab and a Feedback tab in RL Studio. Per-answer feedback controls gated on a new rl_studio capability.

Rules kept

• No tool starts a run, trains, or serves a checkpoint — no_tool_trains_a_model_or_serves_a_checkpoint still passes.
• A run says what it trained on, and an empty build is refused, never run on nothing (ADR 0133).

Where the code and the issue differ (per the instruction to say so)

• Fine-tune execution needs mlx-lm on Apple Silicon, which CI and a Linux box cannot run. So the Rust plumbing (manifest, supervisor command, dataset builder, routes) is unit-tested at the manifest/route level, and the training itself is verified on a Metal machine. mlx_finetune.py is written against mlx-lm's tuner API and reports a clear error where mlx-lm or Metal is absent, rather than pretending.
• The Mac app's RL Studio routes/tests (step 6) are a follow-up; the rename reaches its menu and window title. The desktop CI job stays green (bridge and existing app unchanged).

Tests

• cargo test -p zorp-agent (work-log store round-trip + the keeps-it-out-of-messages assertion, rl_dataset builder), cargo test -p zorp-train (fine-tune config), cargo test -p zorp-web --features train (worklog → feedback → dataset preview, and the empty-fine-tune refusal) all pass.
• web/: npm run check, npm test (incl. new rl-feedback cases and the renamed developer-mode test), npm run build:site pass.
• cargo fmt --all --check and cargo clippy clean for the touched crates.
• ADR 0143 + spec added; CLAUDE.md / AGENTS.md zorp-train bullet updated.

---

Generated by Claude Code

[arjunjaggi34]

CI status on the current head (bbbd417): every gating job is green — build-and-test (ubuntu + macOS), windows, msrv, clippy, web, features, harness, and Desktop App (macOS).

The one non-green check is research-pr, which shows cancelled — the earlier left: 4, right: 3 index-count failure is already fixed on this head (the per-session index assertion is now 4). The cancellation is the job's 60-minute timeout-minutes cap being hit while it builds the bundled DuckDB amalgamation from a cold cache; it is not a code failure. The identical job passed on #298 with a warm shared cache (research-stack), which is the tell that this is cold-build timing, not this PR.

I can't re-run the job myself (the GitHub App lacks actions: write, so a re-run returns 403), and the timeout is a workflow setting I'm deliberately not widening this PR to touch. A maintainer re-run, or the shared cache warming once a research-touching PR lands on main, should clear it. I'll keep watching and report if anything else changes.

---

Generated by Claude Code

---

Generated by Claude Code