Codex/remove aten discovery

.gitattributes

@@ -0,0 +1,3 @@
+# Installed kernel profiles are pinned by SHA-256 of their bytes (profile.json);
+# keep them LF on every checkout so the digests match on Windows too.
+embodiinfer/backend/triton/tuned/*/** text eol=lf

CONTRIBUTING.md

@@ -160,6 +160,131 @@ exclusive, so uv rejects combinations with incompatible Torch or Transformers
 requirements. Declare new dependencies in the right group and regenerate the
 lock against the public index.
 
+### Optional kernel tuning tools
+
+Kernel tuning is repository developer tooling. Its Humanize2 (`hmz`) environment
+requires Python 3.12+, separately from the inference runtime and its model groups.
+
+Real searches run on the Linux/POSIX target machine: the pinned Humanize2 release
+uses POSIX journaling primitives. Task checks and artifact inspection/export also
+work on Windows. Windows CPU tests adapt only that upstream file-write primitive;
+they are not a claim of native Windows coding-agent support.
+
+```bash
+uv sync --project scripts/kernel_tuning --python 3.12 --frozen
+uv run --project scripts/kernel_tuning python -m scripts.kernel_tuning --help
+uv run --project scripts/kernel_tuning python -m scripts.kernel_tuning generate --catalog gated_residual --output results/kernel_tuning/tasks
+uv run --project scripts/kernel_tuning python -m scripts.kernel_tuning check results/kernel_tuning/tasks/gated_residual
+```
+
+For the end-to-end workflow, start with the
+[profiling-to-model-benchmark guide](docs/proposals/0008-kernel-tuning.md#11-automated-tuning-workflow).
+Use `profile` to select registered operators, then `capture-ops`, `calibrate`,
+`tune-all`, `install`, `verify`, and the existing model benchmark. Selection is
+manual; there is no unified `optimize` command. Only registry captures produce
+exports accepted by `install`.
+
+Capture selected registry operators on real inputs in the prepared model runtime,
+with CUDA Graphs and compilation disabled. The driver must execute at least
+warmup + measured steps:
+
+```bash
+/absolute/runtime/python -m scripts.kernel_tuning capture-ops --model pi05 --ops linear,gelu_tanh --warmup 2 --steps 8 --output results/kernel_tuning/captures/pi05 -- /absolute/preparation.py
+/absolute/runtime/python -m scripts.kernel_tuning calibrate --captured results/kernel_tuning/captures/pi05 --output results/kernel_tuning/captures/pi05-calibrated
+uv run --project scripts/kernel_tuning python -m scripts.kernel_tuning generate --model pi05 --captured results/kernel_tuning/captures/pi05-calibrated --list
+uv run --project scripts/kernel_tuning python -m scripts.kernel_tuning tune-all --model pi05 --captured results/kernel_tuning/captures/pi05-calibrated --agent 'HARNESS/MODEL:EFFORT' --set evaluator_python=/absolute/runtime/python
+uv run --project scripts/kernel_tuning python -m scripts.kernel_tuning tune-all --resume results/kernel_tuning/batches/BATCH_ID
+```
+
+`/absolute/preparation.py` constructs the selected policy through `make_policy`
+and runs its inference entries. The shared driver
+`scripts.kernel_tuning.discovery.drive` can replay recorded benchmark inputs.
+Capture freezes real inputs, output layouts, aliases, numerical settings and call
+counts for the selected registry operators. The default fixture budget is 1 GiB;
+increase `--fixture-bytes` if necessary. Calibration freezes per-workload/output
+FP64 bounds before search; every recorded, random and boundary input must pass.
+
+`--ops` selects operators at capture time. All resulting tasks must pass baseline
+preflight before any model search starts. Model batches cannot use
+`--skip-preflight`, partial task selection, estimated shapes or standalone `run`
+to bypass that barrier. `--dry-run` builds tasks without evaluation;
+`--preflight-only` evaluates baselines without agents.
+
+The full-model ATen discovery command `capture --model` has been removed.
+Use `capture-ops`; old discovery artifacts must be recaptured as registry calls.
+The shared capture/task/replay modules keep their existing `discovery.*` paths.
+See [capture artifacts and migration](docs/proposals/0008-kernel-tuning.md#registry-capture-artifacts-and-shared-tooling).
+
+The independent catalog workflow remains available explicitly with
+`generate --catalog`, `tune-all --catalog`, and `capture --catalog`.
+Only it accepts legacy JSONL captures, catalog model groups and `--estimated`;
+catalog exports need separate runtime integration.
+
+Run these commands from the repository root. Humanize2 is pinned to a reviewed
+source revision in the tool's `pyproject.toml`; it drives an existing, separately
+installed coding-agent CLI. Select the harness/model/effort explicitly when
+starting a search. `run` and `resume` execute real agent turns and kernels;
+`check`, `status`, and `export` do not. `check --environment` additionally imports
+the task evaluator and probes dependencies/hardware, without compiling candidates.
+
+On the target machine, set the task's `evaluator_python` to the absolute Python
+executable of its prepared GPU runtime. Install
+`benchmarks/kernel_tuning/requirements.txt` there under that runtime's constraints.
+In particular, preserve Thor's compatible Torch/CUDA/Triton versions; do not copy
+the tooling interpreter's packages or another GPU's Torch pins over them. Inspect
+the proposed dependency changes first, for example with
+`uv --no-config pip install --dry-run --python /absolute/runtime/python -r benchmarks/kernel_tuning/requirements.txt -c /absolute/runtime/constraints.txt`.
+For a separately prepared GPU runtime, `--no-config` avoids applying this
+repository's development-only Torch upper bound. Pin that runtime's Torch,
+Triton, and CUDA packages in the constraints file and inspect the installation
+plan before applying it. When inheriting system packages, verify that the installer
+actually reuses them; do not reinstall the GPU stack just to add the evaluator.
+For a custom evaluator, install only its declared dependencies plus PyYAML.
+
+See the [canonical design and implementation status](docs/proposals/0008-kernel-tuning.md).
+The [workflow guide](docs/proposals/0008-kernel-tuning.md#11-automated-tuning-workflow)
+explains task inputs, the full tuning loop, stopping conditions, and saved results.
+The controller snapshots task inputs, saves all attempts, and exports improving
+solutions with their correctness and timing evidence under `results/kernel_tuning/`.
+Registry exports can be installed into an optional hardware profile, followed by
+whole-model verification, benchmark and review. Other exports require separate
+integration before runtime use; installation alone does not certify a profile.
+For an unregistered operator, the
+[registration workflow](scripts/kernel_tuning/registration/README.md) creates an
+isolated review branch with `register new`, then runs a resumable CPU
+plan/implement/check/repair loop with `register run`. Supply a prepared model
+interpreter using `--set test_python=/absolute/runtime/python` on `new` (and, if
+needed, the first `run`). `finalize` exports the checked patch; commit and push
+are explicit options. This registration gate does not replace target-GPU
+whole-model bit-exact verification before merge.
+Humanize2 agents may execute commands without interactive approval; the scratch
+directory and content hashes are not an OS sandbox. Use an appropriate isolated
+account/container on the target host when needed.
+By default Humanize2 fences each agent session (workdir writable, rest of the
+machine read-only), which needs Linux Landlock: kernel 5.13+ built with
+`CONFIG_SECURITY_LANDLOCK` and listed in `/sys/kernel/security/lsm`. Some vendor
+kernels, such as Jetson L4T, omit it. On such hosts pass `--unfenced` to `run`,
+`tune-all` or `register run`; the choice is frozen into the run, and resume reuses
+it. Unfenced agents can write anything their account can, so run them only under
+a dedicated account without `sudo` or `docker` group membership, or in a container.
+
+CPU tests for the tooling use official Humanize2 fake agents and fake evaluators,
+without a coding-agent account or GPU stack:
+
+```bash
+uv run --project scripts/kernel_tuning python -m pytest tests/kernel_tuning --confcutdir=tests/kernel_tuning -q
+uv run --project scripts/kernel_tuning ruff check scripts/kernel_tuning benchmarks/kernel_tuning tests/kernel_tuning
+uv run --project scripts/kernel_tuning ruff format --check scripts/kernel_tuning benchmarks/kernel_tuning tests/kernel_tuning
+```
+
+CPU registry capture/replay tests also need Torch in the selected interpreter; they do
+not load checkpoints or run GPU tuning. The `--confcutdir` option avoids loading the core test suite's Torch-dependent
+fixtures in the separate tooling environment. Optional numerical/GPU tests skip
+when their dependencies/hardware are unavailable; skips are not GPU validation.
+After preparing the target GPU runtime and CUDA toolkit, exercise both the Triton
+and CUDA C++ builders, byte-level correctness, and changed-input CUDA Graph replay
+with `/absolute/runtime/python -m pytest tests/kernel_tuning/test_numerics.py --confcutdir=tests/kernel_tuning -q`.
+
 ## Checks to run
 
 ```bash

README.md

@@ -212,6 +212,7 @@ Existing `vvla-*` command aliases and `vvla.policy.*` wire schemas remain suppor
 | Integrate or extend the engine | [Architecture](docs/en/architecture.md) · [Python API](docs/en/api.md) |
 | Inspect model behavior | [Models](docs/en/models.md) |
 | Evaluate performance | [Benchmarks](docs/en/benchmark.md) |
+| Profile and tune kernels with an agent | [Kernel tuning workflow](docs/proposals/0008-kernel-tuning.md) |
 
 ## Contributing