@tuned-tensor/cli 0.25.0 → 0.26.1

package/README.md

@@ -72,6 +72,8 @@ npm install -g --ignore-scripts @tuned-tensor/cli
 tt --version
 ```
 
+`TT` also works on case-insensitive filesystems, including standard macOS installs.
+On case-sensitive systems, use `tt` or add a shell alias (`alias TT=tt`).
 Upgrade later with `tt upgrade`. Uninstall with `npm uninstall -g @tuned-tensor/cli` (add
 `--prefix ~/.local` if the curl installer used that prefix).
 
@@ -95,7 +97,7 @@ npm link
 
 `tunedtensor.json` is the source of truth for behavior and training settings.
 In the shell, `/spec` shows a readable overview grouped into behavior,
-examples, training, evaluation and runtime sections; `/spec <section>` (for
+dataset, 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
@@ -176,21 +178,22 @@ the agent:
 ```text
 tt v0.15.0
 agent tunedtensor/managed · workflow model base
-ctrl+c stop/clear · ctrl+d exit · /help commands · tab complete
+tt › What would you like to work on?
+/help commands · ctrl+c stop · ctrl+d exit
 
-Ask TT anything. Known commands run directly.
 › What happened in my latest training run?
 › runs list
 ```
 
-Ordinary sentences go through the locally orchestrated model session. The
+Known commands such as `runs list` run directly; tab completes them. 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
+edits to an existing spec, or prepare a validated `tunedtensor.json` in the shell's current working directory
+when none exists, or prepare a local pipeline dry-run sealed to the reviewed
 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
+traversal, symlinked workspace roots, overwriting an existing spec, 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.
 Prefix a command with `:` when you want to make that intent explicit.
@@ -223,6 +226,10 @@ download with only a training split still needs distinct held-out data.
 
 When a conversation approaches the model's context budget, TT automatically
 summarizes earlier turns using Pi and the selected model, and shows progress.
+The trigger reserves the full reply allowance plus 4,096 tokens for protocol
+headroom; it does not apply an additional percentage reserve. Usage measured
+before a summary is ignored, while new provider usage calibrates the next
+trigger, including after resume.
 The summary preserves goals, decisions and action outcomes and is saved for
 `/resume`; recent exchanges remain in context. Summarization uses an additional
 model request (or several for unusually long histories). The transcript stays
@@ -258,20 +265,63 @@ sealed as `outcome_unknown` for manual inspection. `/reject` never mutates.
 Pipeline dry-runs also wait for `/approve`. Preparation fingerprints the
 workspace directory identity, spec, and adjacent config, revalidates them,
 copies the resolved spec, config, and pipeline into private temporary inputs,
-and invokes `tt pipeline run --dry-run` deterministically. Persisted proposals
-that request real execution fail before the child command is dispatched. Real
-training remains available through the explicit direct `tt pipeline run` command.
+and invokes `tt pipeline run --dry-run` deterministically. A dry-run proposal
+edited to request real execution fails before the child command is dispatched.
+After a dry-run of the same spec bytes completes, the agent can propose a real
+background run with a reason; approval starts it in a detached process and the
+conversation continues. The agent reports progress with read-only tools and can
+cancel a run only through another approval. Each run keeps an audit record
+(reason, requester, choices, resources, outcome and metrics), a hash-chained event
+log and its full log; `TT_MAX_PARALLEL_RUNS` limits concurrent runs. See
+[background runs](docs/local-runtime/background-runs.md). The direct
+`tt pipeline run` and `tt pipeline start` commands remain available.
 A changed workspace or spec requires a new review.
 
+The startup **What you can do** panel covers specs/datasets, decision training,
+LLM fine-tuning, training from scratch, and serving even before a spec exists.
+Decision training can use CPU or Apple MPS; the other training paths currently
+require CUDA locally or a configured AWS GPU. A missing NVIDIA GPU does not
+prevent spec creation or dataset preparation. The banner lists ready workflows on
+one line and shows only the status of the rest; `/system` adds reasons and next steps.
+
+Guidance distinguishes **Ready**, **Needs setup**, **Limited resources**,
+**Remote GPU**, **Needs verification**, and **Unsupported runtime**. Quick
+startup sampling does not install Python dependencies. `tt hardware` explicitly
+checks the locked adapter and decision runtimes separately, including MPS
+availability; it may install those runtimes on first use. It does not download
+models or certify their fit. Old snapshots without a decision probe show
+"Needs verification" until refreshed.
+
+| Platform | Decision training | LLM / foundation training | Packaged LLM serving |
+| --- | --- | --- | --- |
+| Linux x64 / ARM64 | CPU; CUDA when available | NVIDIA CUDA, subject to memory and runtime checks | Linux + NVIDIA CUDA; separate runtime |
+| Apple Silicon macOS | CPU / MPS after runtime checks | Remote AWS GPU | Remote Linux/CUDA host |
+| Native Windows x64 | CPU path; end-to-end training not yet certified | Not certified natively; check a Linux/WSL2 environment or use AWS | Linux/CUDA host |
+| Intel macOS / Windows ARM64 | No compatible wheels in the current lockfiles | Remote AWS GPU | Remote Linux/CUDA host |
+
+The native Windows CI job verifies hardware discovery and displayed guidance,
+not model training. WSL is assessed as its own Linux environment. AMD/Intel GPU
+acceleration is not enabled by the packaged CUDA runtime. Decision resource
+warnings use conservative advisory thresholds (8 GiB available working memory,
+6 GiB free model-cache disk, 4 CPU cores); they are not measured model minima.
+Batch size, sequence length, training mode and other running applications matter.
+CPU evaluation does not imply that `tt serve` can run on CPU. Agent chat still
+needs managed access or your own model provider; local data commands need neither.
+
 Useful shell controls include `/help`, `/status`, `/context`, `/system`,
-`/model`, `/login`, `/cd`, `/clear`, and `/exit`.
+`/usage` (managed agent allowance and token usage), `/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
+CPU, RAM, and free space on the model-cache filesystem) 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.
+On macOS, RAM marked `in use (est.)` excludes estimated reclaimable file cache;
+decision-training warnings use the same available-RAM estimate. This is not a
+memory-pressure measurement or a guarantee that a workload fits. CPU load is a
+one-minute average, separate from the sampled utilization percentage. Disk usage
+describes the filesystem containing the cache, not the size of downloaded models.
 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
@@ -652,6 +702,13 @@ Commit the lock file with the spec. Runs that load the base model from
 `--verbose` adds training and evaluation process output, and `--quiet` hides
 both. Full logs stay in the run directory either way.
 
+Adapter evaluation batches four prompts by default, reports
+completed examples and ETA, and saves completed batches for recovery. Set
+`evaluation.inference.batchSize` to tune memory use; `evaluation.maxExamples`
+and `sampleSeed` select an explicit smoke sample. Matching interrupted
+baselines automatically continue on retry with the default baseline cache.
+See [evaluation settings and recovery](docs/local-runtime/architecture.md#evaluation).
+
 Every run report has a `provenance` block recording what produced it:
 
 - TT, Node and platform versions, and the digest of the locked Python runtime;
@@ -756,6 +813,26 @@ For the full command reference, including long-example policies, eval token
 budgets, evaluation caps, and local model serving, see the
 [CLI docs](https://tunedtensor.com/docs/cli).
 
+### Split a master dataset
+
+Keep converted datasets as unsplit chat JSONL. Downloaded chat JSONL can be
+split directly from its verified cache: ask the agent to inspect the download
+and use its pinned `split_source`, with no manual copy. Ask it to split a named
+file with your ratios and seed, then attach the approved paths to your spec.
+For example: “Split data.jsonl 80/20 for training and validation with seed 123,
+stratify by metadata.category, and save to split-123.”
+
+```sh
+tt datasets inspect data.jsonl
+tt datasets split data.jsonl --output split-123 --train .8 --validation .2 --test 0 --seed 123
+```
+
+The source stays unchanged. Groups containing repeated prompts stay in training
+so held-out prompts remain unique;
+optional `--group-by` and `--stratify-by` support family and label boundaries.
+See [splitting local data](docs/spec-workflow.md#splitting-an-unsplit-dataset)
+for defaults, metadata preservation, and benchmark holdout limitations.
+
 ## Development
 
 ```bash

package/dist/{chunk-UCJCWJ6F.js → chunk-4BHDPRYD.js}

@@ -250,6 +250,7 @@ async function listArtifactFiles(root, current = root) {
       throw new Error(`Artifact tree must not contain symbolic links: ${absolute}`);
     }
     if (entry.isDirectory()) {
+      if (portableRelative(root, absolute) === "inference-checkpoints") continue;
       files.push(...await listArtifactFiles(root, absolute));
       continue;
     }
@@ -1341,6 +1342,7 @@ var runReportSchema = z.object({
   created_at: z.string()
 }).strict();
 var inferenceConfigSchema = z.object({
+  batchSize: z.number().int().min(1).max(128).default(4),
   maxNewTokens: z.number().int().min(1).default(256),
   temperature: z.number().min(0).default(0),
   topP: z.number().min(0).max(1).default(1),
@@ -1352,6 +1354,7 @@ var scoringConfigSchema = z.object({
 }).strict();
 var evaluationConfigSchema = z.object({
   inference: inferenceConfigSchema.default({
+    batchSize: 4,
     maxNewTokens: 256,
     temperature: 0,
     topP: 1,
@@ -1389,6 +1392,7 @@ var localRunnerConfigSchema = z.object({
   }).strict().default({}),
   evaluation: evaluationConfigSchema.default({
     inference: {
+      batchSize: 4,
       maxNewTokens: 256,
       temperature: 0,
       topP: 1,
@@ -1747,7 +1751,7 @@ function buildDecisionPythonCommand(entrypoint, args = []) {
     "--project",
     decisionProject,
     "python",
-    join3(decisionProject, "src", entrypoint),
+    entrypoint === "-c" ? entrypoint : join3(decisionProject, "src", entrypoint),
     ...args
   ];
   return { command: "uv", commandArgs, displayCommand: ["uv", ...commandArgs] };
@@ -2241,7 +2245,7 @@ async function enforceSpecLock(args) {
         `Base model ${model.id}@${revision} is not downloaded (${snapshot}). Run \`tt models prefetch\` with this spec first.`
       );
     }
-    const { prefetchBaseModel: prefetchBaseModel2 } = await import("./prefetch-GP3OPUUL.js");
+    const { prefetchBaseModel: prefetchBaseModel2 } = await import("./prefetch-DH365HNN.js");
     await prefetchBaseModel2({ request: args.request, config: args.config, reporter: args.reporter });
   }
   const { files } = await snapshotDigests(snapshot);
@@ -2770,6 +2774,9 @@ export {
   localBehaviorSpecFileSchema,
   isFoundationSpecFile,
   isDecisionSpecFile,
+  minimalMachineLearningEnvironment,
+  withHuggingFaceCacheEnvironment,
+  withOfflineHuggingFaceCacheEnvironment,
   reportInBackground,
   withProgressHeartbeat,
   sanitizeLogLine,
@@ -2786,9 +2793,12 @@ export {
   withFoundationPythonEnvironment,
   ProcessCancelledError,
   runLoggedProcess,
-  minimalMachineLearningEnvironment,
-  withHuggingFaceCacheEnvironment,
-  withOfflineHuggingFaceCacheEnvironment,
+  verifyModelPrefetchCacheReport,
+  buildModelPrefetchPayload,
+  buildModelSourcePrefetchPayload,
+  safeName,
+  verifyLocalBaseModel,
+  prefetchBaseModel,
   snapshotDigests,
   recordAssetDownload,
   listAssets,
@@ -2798,12 +2808,6 @@ export {
   readSpecLock,
   writeSpecLockEntry,
   applySpecLock,
-  enforceSpecLock,
-  verifyModelPrefetchCacheReport,
-  buildModelPrefetchPayload,
-  buildModelSourcePrefetchPayload,
-  safeName,
-  verifyLocalBaseModel,
-  prefetchBaseModel
+  enforceSpecLock
 };
-//# sourceMappingURL=chunk-UCJCWJ6F.js.map
+//# sourceMappingURL=chunk-4BHDPRYD.js.map