werbos

← All log entries

Day 31 — 'the training view lands.'

Day 30 trained werbos-0.0.1 and shipped the read-only /api/training/* backend — but the only consumer was a commit message. Day 31 gave the ratchet a face: TR.1 frontend on BOTH SPAs (the chat-ui Training view and the operator dashboard's /training route), each a promoted-baseline card + cycles ledger with signed deltas, a 2.5σ-clears chip, and ★promoted markers, drilling into per-cycle candidate/baseline/noise eval tabs. Then adapter discoverability closed the last gap: 'werbos train list' enumerates ~/werbos/adapters/ and bare 'werbos chat --model werbos-0.0.1' resolves against the adapters root — usable AND findable. Docs reframed the whole narrative around self-training-as-shipped. werbos-0.0.1 is now on disk, on two dashboards, and callable by name.

“the training view lands.”

Day 30 produced werbos-0.0.1 and the /api/training/* endpoints to describe it — but nothing rendered them. The first ratchet click existed only as a number in a commit message. Day 31 was making it something the operator can look at.

TR.1 frontend — the Training view (67d4f77)

Wired the chat-ui’s Training surface to the live routes that had no consumer:

  • TrainingView.tsx — promoted-baseline banner + cycles ledger (signed deltas, clears-2.5σ marker, ★promoted) + per-cycle eval drill-down with candidate / baseline / noise tabs.
  • api.ts — real fetches, including the 204 no-promotion state that getTrainingBaseline has to handle gracefully.
  • types.ts — TrainingCycle / TrainingBaseline / EvalRow mirroring the tr/1 camelCase wire exactly.
  • _training.scss — reuses the eval .probes visual language so it reads as one surface, not a bolt-on.

Read-only by design: training and promotion stay in the werbos train CLI. This just makes werbos-0.0.1 visible.

TR.1 — the operator dashboard route too (4e12e4a)

The operator dashboard (Models / Scheduler / Settings) had its own blind spot — the training routes only fed the chat-ui. Added a /training route right beside Models: promoted-baseline card (composite / 2.5σ / σ / base) + the same cycles ledger with delta-colored-by-sign, ✓ 2.5σ chips, and ★promoted / train-failed chips. Both SPAs now surface the same ratchet.

Adapter discoverability (b2c5f6c)

A trained model was usable but not findable. Closed both halves:

  • werbos train list — enumerate ~/werbos/adapters/ (name / base / composite / delta / promoted+clears flags), single-sourced off the TR.1 discovery scanner. --json for the full tr/1 records.
  • Bare --model names — _detect_trained_adapter now resolves werbos chat --model werbos-0.0.1 against the adapters root ($WERBOS_ADAPTERS_DIR, else ~/werbos/adapters). Explicit dir paths still win; precedence matches discovery. +8 tests.

Docs caught up to reality (cbc39bd, 94873b4, 7f6216a, 5357fca, 5b81646)

Self-training shipped, so the story had to stop saying “coming soon”: README narrative reframe + status rows, werbos chat --model help mentioning trained adapters, THESIS capability-list refresh, a fresh ROADMAP.md + onboarding section, and the werbos-map.md capability map uploaded.

Numbers worth keeping

  • Two SPAs now render the ratchet (chat-ui + operator dashboard)
  • werbos train list — one command, the whole adapter shelf
  • Bare-name --model resolution — 8 new tests guarding it

AHAs

  • “Usable isn’t the same as findable.” werbos-0.0.1 worked on Day 30, but you had to already know its path. A model you can’t list and can’t name by hand isn’t really shipped.
  • The dashboard convention from Day 30 paid off immediately — two independent React surfaces consumed the exact same wire shape with zero contract negotiation.

Tomorrow

The ratchet is visible. Next is keeping it fed (nightly training) and getting the repo ready for strangers to read.