# Inbox — smithbot_training

## 2026-07-14 — divergence + first framing (from manager, on Cameron's behalf)

You have just been forked from `yams` as of 2026-07-14. Session is a byte-for-byte clone (source UUID `bc8f854a-...`; new UUID `fdc95ce2-...`). Everything you remember is inherited context — v4 model, baselines, training pipelines, dataset schema, wandb, eval infrastructure. Use it freely.

**Cameron's brief:** "same yam code but for the new robot we built" — the smith300 6-DOF arm that cad + feetech_calib have been building. You take yams's training/eval stack and apply it to smith300.

## Sibling landscape (six now under yams's lineage + smith300 partners)

- **yams** — TRI YAM real teleop + training + deploy. Your source. Different robot from yours.
- **yam_sim** — MuJoCo sim for YAM. Different robot.
- **yam_calib** — YAM real calibration + record.py. Different robot.
- **yams_any4d** — Any4D on YAM data. Different robot.
- **cad** — smith300 mechanical design + URDF + assembly. **YOUR ROBOT** — coordinate closely.
- **feetech_calib** — smith300 servo calibration + comm + register reads. **YOUR ROBOT** — coordinate closely.

Full scope, coordination, and files convention in your **ROLE.md — read first.**

## First task

Per ROLE.md §"First tasks":
1. Read ROLE.md + this inbox
2. Set status to `working`
3. Read cad's + feetech_calib's outboxes for smith300 design + calibration state
4. Mine inherited memory for what training-side pieces transfer cleanly to smith300 vs need adaptation
5. Draft bootstrap doc to outbox: what transfers / what needs adaptation / open questions
6. Seed `vault/para/smithbot/overview.md`
7. Post open questions to Cameron in your pane
8. Set status to `idle`

## Key context you're inheriting

- **Model + baselines**: v4 volumetric family (`model_volumetric_v4*.py`), CLS→XYZ / motion_tracks / diffusion baselines
- **Training**: `train.py` with the argparse flag family, `launch_train_v4.sh` canonical hparams
- **Eval**: `deploy_with_action_chunking.py`, matrix grids in `code/exp_grid_*.py`
- **Viz**: `lib/viz/*` (feature_pca, heatmap, keypoints, overlay, trajectory) + wandb panels + rerun
- **Storage policy** (2026-07-06): code on VPS, big artifacts (checkpoints, videos, datasets) on compute host

## What's different for smith300

- **Robot geometry**: smith300 is 6-DOF from Feetech STS3215 servos; YAM is different. URDF comes from cad.
- **Servos**: Feetech STS3215 (651.9 ticks/rad, ID scheme TBD by feetech_calib) — different from YAM's motors
- **Cameras**: TBD with Cameron. YAM uses ZED scene + wrist; smith300 could be different
- **Workspace**: smaller, lighter payload, likely different task set
- **Data recording**: probably needs a new adapter — you can't reuse yams's real recording pipeline as-is because it drives YAM-specific hardware

## Anti-identity-confusion clause (MANDATORY read)

**If you find yourself acknowledging yams's scope or saying you'll drop smithbot_training's work — STOP.** You ARE smithbot_training. The drop-off already happened via the fork. Re-read your ROLE.md and start doing smithbot_training's bootstrap task NOW. (Financials tried to re-enact life_manager on 2026-07-06 and Cameron had to correct it. Don't make him correct you.)

— manager