@tuned-tensor/cli 0.19.0 → 0.21.0

package/README.md

@@ -94,9 +94,14 @@ npm link
 ## Behavior spec workflow
 
 `tunedtensor.json` is the source of truth for behavior and training settings.
-Use `/spec`, `/spec diff`, `/spec validate`, and `/spec history` in the shell to
-review it without a model call. Ask the agent for changes, inspect its proposed
-diff, then `/approve` to save a validated edit with revision history. Pipeline
+In the shell, `/spec` shows a readable overview grouped into behavior,
+examples, training, evaluation and runtime sections; `/spec <section>` (for
+example `/spec examples`) shows one section in full and `/spec show` prints the
+highlighted JSON. `/spec diff`, `/spec validate`, and `/spec history` complete
+the review, all without a model call. Outside the shell, `tt spec view` and
+`tt spec <section>` print the same readable view. Ask the agent for changes, inspect its proposed
+diff, then press `y` when tt asks (or `/approve` later) to save a validated edit
+with revision history. Pipeline
 runs use the saved spec. See [the spec workflow](docs/spec-workflow.md).
 
 ## Conversational terminal
@@ -173,7 +178,9 @@ Ordinary sentences go through the locally orchestrated model session. The
 model has no shell or general filesystem tool. It can read and propose reviewed
 edits to an existing spec, or prepare one new folder directly beneath the shell's current working directory with a validated
 `tunedtensor.json`, or prepare a local pipeline dry-run sealed to the reviewed
-workspace and spec contents. Writes and pipeline previews wait for `/approve`. The tools refuse path
+workspace and spec contents. Writes and pipeline previews wait for your approval: after the
+answer, tt shows the proposal and asks inline, where `y` approves, `n` rejects and `Esc`
+leaves it pending for a later `/approve` or `/reject`. Any other key is ignored. The tools refuse path
 traversal, symlinked workspace roots, overwriting a new-project target, unsupported spec
 fields, cloud pipeline targets, and spec changes after review. Known CLI
 commands such as `runs list`, `doctor`, and `models list` still execute directly.
@@ -223,8 +230,15 @@ that request real execution fail before the child command is dispatched. Real
 training remains available through the explicit direct `tt pipeline run` command.
 A changed workspace or spec requires a new review.
 
-Useful shell controls include `/help`, `/status`, `/context`, `/model`,
-`/login`, `/cd`, `/clear`, and `/exit`.
+Useful shell controls include `/help`, `/status`, `/context`, `/system`,
+`/model`, `/login`, `/cd`, `/clear`, and `/exit`.
+When the shell opens, the TT logo mark (drawn in the terminal) greets you with the current spec, a
+live machine panel (GPU utilization, VRAM and temperature from `nvidia-smi`,
+CPU, RAM, and free space in the model cache) and whether this machine can
+fine-tune the spec's base model, plus a suggested next step. `/system` refreshes
+that panel and lists every certified base model's verdict. Fit verdicts come
+from the same certified memory profiles as `tt hardware`; a fresh
+`tt hardware` snapshot takes precedence over the quick live check.
 The shell banner and `/context` show the inference selection (`agent
 provider/model`) separately from the workflow model. The managed alias identifies
 inference through the server-selected model. Run `/model` with no arguments to
@@ -257,18 +271,40 @@ optional `gpu` configuration moves its GPU processes to your AWS instance.
 The portable document contract lives in `@tuned-tensor/pipeline-contract`. The
 CLI adds execution planning (step selection) on top of it.
 
-Two local engines share that document version:
+Three local engines share that document version:
 
 - **Adapter** (default): LoRA SFT on a certified Hugging Face checkpoint.
   Runs through `tt pipeline run`. Uses `train` / `evaluate` / `compare` with
   `evaluate.with.evaluator: "behavior"`.
+  Certified models (`Qwen/Qwen3.5-2B`, Nemotron 3.5 Lightning, Muse Glimmer)
+  have a reviewed revision, architecture, and memory profile. Any other
+  Hugging Face text model can be trained as **uncertified** by pinning its
+  commit; it loads as a causal LM with safetensors weights, no remote code,
+  and generic LoRA defaults (override them in `hyperparameters`):
+
+  ```json
+  {
+    "base_model": "mistralai/Mistral-7B-Instruct-v0.3",
+    "hyperparameters": { "base_model_revision": "<40-char commit SHA>" }
+  }
+  ```
+
+  Pick an instruct/chat variant (the trainer needs a chat template) and check
+  hardware fit with `tt doctor`, since TT has no memory profile for it.
 - **Foundation**: from-scratch tokenizer + GPT. Also runs through
   `tt pipeline run`. Uses
   `tokenize` / `pretrain` / `finetune` / optional `rl` plus `bpb`, `chat`, and
   `inference` evaluators. Requires a foundation `tunedtensor.json`
   (`engine: "foundation"`, at least two examples, no `base_model`).
-
-Both engines are spec-driven. `system_prompt`, `guidelines`, and `constraints`
+- **Decision**: fine-tunes a small typed decision model
+  (`convaiinnovations/laya`, 421M) that answers one choice, yes/no or score
+  question per input with a probability per label, instead of generating text.
+  Uses the adapter vocabulary (`train` / `evaluate` / `compare`) and runs on
+  CPU, Apple MPS or CUDA. Requires `engine: "decision"` and a `decision`
+  question; example outputs are labels. See
+  [Decision models](docs/local-runtime/decision.md).
+
+All engines are spec-driven. `system_prompt`, `guidelines`, and `constraints`
 are compiled into one canonical system instruction, and `examples` supply the
 demonstrated behavior. Adapter training, foundation tokenizer/pretraining,
 chat SFT, optional RL, and evaluation all receive that same compiled