Repository navigation
batch: land #248, #251, #250, #249, #247, #243 - #262
Merged
Merged
Conversation
H54q had no runner, and amendment Q1 asks for one before its first hold. This adds it. - arm.sh gains an item mode, which hold.sh turns on for row q. Each arm answers its GSM8K items 16 in flight, using H54a's chat and grader. Every finished request is written as it lands. No request starts after an item stop 90 s before the hold's deadline. An item's first error re-asks it once; a second error counts as wrong. - When the server stops answering, the arm is failed and the run of errors is discarded. - OVQ, OVB and Lg apply the manifests H54a's scored runs applied, byte for byte. R and Vi derive from H54a's recorded B1g render. - qcampaign.sh plans each of the three holds from the records so far. - h54.py score-q pairs items 0-199 and bootstraps OVQ - R and OVB - OVQ (10,000 resamples, seed 1). - The tests cover the renders, the record rules, the plan, the client against fakes and a local stub server, and the verdicts.
…ecord around the holds Neither step is part of H54q's protocol or score. verify hashes every weight file the arms load against the pre-registration's sha256 list and OVQ's manifest, under the bench lock. frontdoor records that both SGLang serving pairs still answer through Dynamo :8100, with each pair's request counter rising.
…s the fix integrations/eas/overlay.py decides, per row of integrations/eas/overlay.json and at one EAS commit, whether a k3s/k3d patch is skipped (not needed on this cluster), dropped because upstream merged it (git apply -R --check), dropped because upstream fixed it another way (a probe matches and the knob the generator writes is still there), applied (first variant whose git apply --check passes), or a STOP that names the upstream change that moved the hunk and says to regenerate. Every decision prints as `fact -> choice [source]`, with --explain giving permalinks. Decisions read the commit through a scratch index, so they do not change once the overlay is applied; --apply writes the working tree only when nothing STOPs, and a re-run is a no-op. Patches are looked up in integrations/eas/patches, then in the upstream drafts, so the drafts stay the only copy. The one new patch is the release-1.2 form of 0006, where the EnvoyProxy task is still in roles/envoy_gateway/tasks/install.yaml. tests/eas_test.sh (section overlay) runs it on synthetic git repos built from byte-identical copies of the EAS files the patches touch, at main 97f6157 and release-1.2 5c27fb3. apply-check.sh gains --overlay, which checks the recorded decisions on a real clone and prints them for branch tips and open EAS PRs #50, #52 and #61.
… on the load gate The two holds left of H57d's cap ran on 2026-10-29 from c4407a2, as amendments R1 and R2 register them: H57d's revisions downloaded again and checked against the committed weights.sha256, the drafter rebuilt to H57d's Q4_0 (8eb21d5b...), a discarded wiring smoke, then holds 1 and 2 under ~/k3dgpu-bench.lock in their registered orders. All six arm runs were measured and the affinity check passed. score-p reads both rows INCONCLUSIVE: the load gate's foreign P-core load spread is 2.97 CPU-s/s (> 2.0), Od 0.45 against the llama.cpp arms' 3.1-3.4. Not gated: Ld-mtp-u/Ld-mtp 1.108 (95% CI 1.072-1.142), faster in both holds; Ld-mtp-u/Od 1.369 (1.345-1.396). Disclosed deviation: Od ran without the P-core balloon (cpuset 0-15,17-31, request 1 CPU). arm.sh calls k3d-gpu agent manifest without K3D_GPU_CLUSTER, and since #183 that call names the context k3d-gpu, which a hold's kubeconfig lacks, so the manifest saw no hybrid node. Records under bench/h57d/results/2026-10-29 (re-scoring them reproduces verdict.json); the technical report's counts move to 30 INCONCLUSIVE and 17 PENDING.
F3 is one scored run of `k3d-gpu eas up --agent-toolkit` on a fresh, default k3d-gpu cluster on the i9-13900T at the "main" profile pins (EAS 97f6157, enterprise-inference 3e8a244, EAT release-2.0.0 036b662). It grades the printed auto-choices and overlay decisions against a fixed table, the install's PLAY RECAPs, a Ready wait, `eas check` through the EAS gateway, a secret scan over logs and sampled argv, and `eas down`. The row is PENDING; the run waits for the eas CLI and the eat-up.sh release-1.1.0 move to reach main.
…emory as read Od's memory limit and agent-fit differ between the holds (36Gi and cpu 6x131072 in hold 1, 39Gi and cpu 7x131072 in hold 2), since the fit sizes them from MemAvailable at render time; the run section quoted hold 1's only. Its serving arguments, image, graph.pbtxt and cpuset are the same in both holds, so the pooled records stay one treatment. qwen35-9b holds 13,530 MiB of GPU 1 as nvidia-smi reads it (13.2 GiB), not 13.5 GiB. Rebased onto main after H52b's run: the technical report now counts 17 REFUTED, 30 INCONCLUSIVE and 17 PENDING, and its status line names the H57dp run.
New page docs/intel/eas.md (in the nav under Integrations) documents `k3d-gpu eas`: what "full EAS" covers, the commands, every automatic choice with the fact it reads and a permalink to the upstream line behind it, the refusals, the patch overlay with its expected decisions for the main and v1.2.0-rc.1 profiles, the pins and how to move them, EAT's hardware and inotify minimums against what `eas up` does on a smaller host, the known issues, and the limits (Xeon CPU path only; Arc and Gaudi stay with `k3d-gpu agent up`; ERAG refused until an enterprise-inference vLLM-XPU runtime exists). docs/intel/upstream-eat.md gets a second 2026-10-29 re-read and a new SHA table: EAS main 97f6157 still passes every patch and the series; on v1.2.0-rc.1 (5c27fb3) 0005 and 0006 fail, which the overlay's second 0006 variant covers; open EAS PRs #50 and #52 break 0006 and #61 breaks 0002, 0004 and 0005. It lists the source findings for a k3d BYO install of EAT 2.0 and says Gate 2 covered platform and inference only, so EAT 2.0 on k3d stays unverified until F3 runs. docs/platforms.md, docs/intel.md, README.md and the upstream pack README now name the two paths: eat-up.sh on EAT release-1.1.0 for EAT 1.x, and `k3d-gpu eas up --agent-toolkit` for EAT 2.0, with F3 PENDING.
tests/eas_test.sh gains a config section, next to the overlay section, that runs integrations/eas/eas-config.py on nineteen golden fixtures under tests/fixtures/eas/config. Each fixture is a facts.json and an args line, and the expected k3d-gpu-overrides.yaml, global_config.edit.yaml, models.edit.yaml, repos.<layer>.yaml and choices.txt must come out byte for byte. Refusal cases must exit 3, print the expected reasons and write nothing. The fixtures cover: - the desktop (hybrid, baked balloons, no AMX, Arc GPU, 125 GiB, 32 CPUs) - a Xeon with AMX and no NRI policy, and a Gaudi box - ServiceLB disabled, k3d-gpu's own agent-sandbox, and EAT 1.x namespaces - rootless Docker, NRI off, and a host where no model fits - the erag layer, the v1.2.0-rc.1 profile, and the inference layer - --model overrides, including one fit rejects - a re-run over EAS's own Helm releases with custom CIDRs - stock k3s, Istio's default, and unknown CNI layouts - fit failing for one candidate The balloons and NFD DaemonSet metadata, the k3s.io/node-args format and the containerd CNI bin_dirs come from a live k3d-gpu v1.37.1 node. The k3d-gpu balloons DaemonSet carries the chart's Helm labels as well as the k3s addon annotation, so ownership is read from the annotation. The section also checks that the generator needs only the Python standard library, that floating refs and malformed facts exit 2, and that a refusal or a second run leaves no stale output. It checks that --explain prints permalinks, that every citable source is a permalink at a full commit SHA, and the pins.json shape. It fails now (5 passed, 30 failed): the generator and pins.json do not exist yet. The overlay section is unchanged and passes.
…ream SHAs
integrations/eas/eas-config.py turns read-only facts about a k3d-gpu cluster
into what Intel's Enterprise AI Solutions installer (es_auto_installer.sh,
existing_kubernetes mode) needs:
- ansible extra vars, passed last so they win
- the existing_kubernetes key for global_config.yaml
- edits to models.yaml, the file model-manager reads
- the layer manifest's revs, as commit SHAs
- one line per choice: "<fact> -> <choice> [<source>]"
Each source is a permalink at the tree it was read from: EAS 97f6157, EI
3e8a244, EAT 036b662, k3s v1.37.1+k3s1 356c025, vLLM v0.28.0 2cf0a69, and this
repo's Gate 2 probe records. --explain prints the permalinks. The generator is
pure (no cluster access) and uses only the Python standard library. Strings are
quoted, while booleans and lists keep their YAML types, because ansible-core
2.19 rejects a quoted "false" in a conditional. The facts schema is in the
docstring for the part that gathers them.
Choices:
- istio_platform from containerd's CNI bin_dirs: k3d for k3d-gpu's node image,
which needs overlay 0002.
- metallb_enabled false while ServiceLB is on.
- kubernetes_cpu_policy best-effort when a k3s-addon balloons DaemonSet is
present, Docker is rootless or containerd NRI is off. Otherwise nri-balloons,
flagged as needing overlay 0003. Overlay.py makes that decision from this
policy.
- nfd_enabled false next to k3d-gpu's NFD.
- require_amx from the AMXBF16 label.
- The k3s CIDRs.
- kata off on a bring-your-own cluster.
- kubernetes_accelerator cpu, with a note to serve any GPU or Gaudi through
k3d-gpu agent up.
On the agent-toolkit layer:
- agent_sandbox_enabled.
- The model: EAT's default when the node has the 131 GiB EAT documents and
k3d-gpu fit agrees, else the first documented 64 GiB fallback that fits,
else none. --model overrides the pick.
- The KV cache from fit, but only below the catalog's value. The catalog's
memory is the pod's limit, and fit sizes against the host.
Refusals exit 3 and leave nothing in --out:
- ServiceLB disabled
- EAT 1.x namespaces
- k3d-gpu's own agent-sandbox, or any version other than EAT's v0.5.0
- a CNI layout no Istio profile matches
- the erag layer: ERAG's Intel GPU flavour is experimental, and EI has no
vllm-xpu runtime
Floating refs exit 2: only a pins profile or a full SHA is accepted.
integrations/eas/pins.json (k3d-gpu.eas-pins/v1, checked 2026-10-29) holds flat
rows {profile, name, repo, ref, sha, date, source}:
- profile main: EAS main 97f6157, EI main 3e8a244, and EAT release-2.0.0
036b662, the same tree as the agentic-toolkit-migration branch EAS main names
- profile v1.2.0-rc.1: EAS 5c27fb3, EI release-1.1 170eb3a and EAT 036b662, as
in the release notes
- the bastion tools: kubectl v1.37.2, helm v3.22.1, yq v4.54.1, kubernetes.core
6.3.0, ansible 12.3.0, kubernetes 35.0.0, jsonpatch 1.38, jmespath 1.1.0, and
ubuntu:24.04 by digest
Every head was re-read with git ls-remote and gh api before this commit.
A mutation pass of 19 mutants over the generator is killed by the config
section. Both sections pass (220 checks).
Three of F3's INCONCLUSIVE conditions always also meet a REFUTED one: step 3 stopped at 100 min while pods are still pulling exits non-zero, a registry or Hugging Face error fails the step it happens in, and a run where no model fits cannot pass `eas check`. Without a rule the grader could pick either verdict after the fact. The added precedence paragraph, written before any F3 step, grades such a consequence INCONCLUSIVE and every other REFUTED condition, a choice or overlay decision that differs from the table included, REFUTED. The prediction and every condition are unchanged.
…tes to source Read against EAS 97f6157, enterprise-inference 3e8a244, EAT 036b662, ERAG 319eb46 and Envoy Gateway v1.7.1: - LiteLLM and Langfuse are not part of a plain inference install. EI enables them only with auth_type litellm_vkey (components.yaml L42-L53) and defaults to jwt (config.yaml L44), which is how Gate 2 probe 5 reached its model; EAT's layer config sets litellm_vkey (config.yaml L24). The layer table, `eas check`, the curl line and the secrets note now say LiteLLM comes with --agent-toolkit. - No Service is named eg-gateway. eg-gateway is the Gateway; EAS sets no Service name, so Envoy Gateway names the proxy Service envoy-<ns>-<name>-<hash> (resource_provider.go L299-L304). Step 5 reads the Gateway's status.addresses. - ERAG's default flavour, chatqna, is a Xeon (CPU) deployment (deployment/README.md L3), so the missing EI vllm-xpu runtime only blocks its experimental Intel GPU flavour. The docs now say ERAG is not wired in yet and is the follow-up on the same CPU path, instead of refusing it for the GPU reason; README no longer says the three layers are all EAS ships on Xeon. - The --skip-models row: EI's seeded config already has llm_services_deploy_models false, and with --agent-toolkit the chat model and the Qwen3Guard guard deploy whatever that key says (llm_services install.yaml L143-L161). The row and the `--` example now use llm_services_autodeploy_models [] and say the guard model stays. - The installer runs ensure_sudo before every install and adds --ask-become-pass without passwordless sudo (es_auto_installer.sh L866-L875, L1179, L1423); the Limits note names it for the CLI part's bastion. - Smaller fixes: #61's 0005 is skipped because it is docs, not because of the node count; the pod CIDR fallback only matters once LiteLLM admits the pod network (OpenShell); k3d-gpu owns the balloons policy on a hybrid or multi-NUMA host.
…and the checks Three holds on crescent under amendments Q1 and Q2, plus one discarded wiring smoke. Each arm's turn has items.jsonl (one row per finished request), q.json, status.json, deploy.yaml, server.log and its readiness files. Each hold has reproduce.txt, pre.txt, post.txt, serving.jsonl and hold.log. The campaign has plan-hold1-3.txt, not-run.txt and score-q.json. The weight check and the before and after front-door records are included. Kubeconfigs are left out, and logs over 20 kB are gzipped.
…s the bf16 quality, the base-model IR is not worse H54q ran to its pre-registered protocol (amendment Q1, runner amendment Q2) in 3 of its 3 holds. R, OVQ, OVB and Lg answered all of GSM8K items 0-199, with no errored item. Correct of 200: R (bf16 QAT, vLLM CPU v0.32.0) 194, OVQ 191, OVB 192, Lg 193. - OVQ - R is -0.015 (95% CI -0.035 to 0.000). Its lower bound clears the -0.05 margin. - OVB - OVQ is +0.005 (CI -0.015 to +0.025). It is neither below 0 nor above it. - Only one SUPPORTED bound holds and no REFUTED bound does, so the row reads INCONCLUSIVE. That is the verdict it predicted most likely. - Vi was not deliverable: vLLM v0.32.0 cannot load the AutoRound MoE checkpoint. This commit adds the row's verdict, a falsification-log entry and the run section with its Reproduce header. The technical report now counts 29 INCONCLUSIVE and 19 PENDING and gains an H54q row. docs/intel.md's H54q row is updated, and the README no longer says H54q has yet to measure the QAT conversion.
# Conflicts: # docs/intel/technical-report.md
F4 is H1b's user path on the i9-13900T after eat-up.sh moves from release-1.0.3-hotfix to release-1.1.0: k3d-gpu up with the README's EAT env, eat-up.sh, eat-up.sh model cpu-qwen3-1-7b, the readiness wait, then eat-check.sh passing chat, a tool call and the sandbox's 385. Functional, n = 1. It is written before any step runs, and no doc may call the release-1.1.0 path verified until it is SUPPORTED.
eat-up.sh clones release-1.1.0 at 0c726f5, the latest EAT release (2026-10-22), in place of release-1.0.3-hotfix at 0d3438d. What the move needs, read from release-1.1.0's source: - The guardrail. deploy-agentic-stack.sh sets DEPLOY_GUARDRAILS to "on" when it is sourced (line 195), and fresh-install.sh deploys the Qwen3Guard guardrail when it is on (line 419). Only main() reads deploy_guardrails from agentic-config.cfg (line 1138), and the sourced brownfield run skips main(), so the config key alone changes nothing. brownfield.sh now reads deploy_guardrails the way read_config_file reads every other toggle and exports DEPLOY_GUARDRAILS before sourcing; with no value, EAT's default stands. - agentic-config.cfg writes release-1.1.0's new toggles out as off: deploy_guardrails, deploy_vllm_sr, deploy_openshell, deploy_kata_containers, deploy_ceph and rack_scale_mode. - vllm-values.yaml pins vllm/vllm-openai-cpu v0.28.0, the tag release-1.1.0's xeon-values.yaml names, by its index digest sha256:197354e6...df9647 (Docker Hub, read 2026-10-29). images.lock follows. - release-1.1.0 ships OpenShell, so the deploy_openshell=on refusal now says why it stops: OpenShell has not run on a k3d-gpu cluster. tests/eat_test.sh checks the tag and commit, the six toggles as EAT's read_config_file reads them, the guardrail hand-off (absent, on, off, quotes, last assignment wins, the shipped config), the vLLM digest, the refusal text, and that the gateway chart copy keeps release-1.1.0's hybrid-router callback and customRouter switch. The release-1.1.0 path has not run; it is ledger row F4.
…ified integrations/eat/README.md: the pin and its pins table (EAT, bastion, Helm, the vLLM CPU v0.28.0 digest, the gateway charts), the 1.1.0 gateway's hybrid router (a ConfigMap, no new image; the copies still differ from EAT's charts only in the 11 image lines, rendered with Helm v4.1.1 on 2026-10-29), blocker 11 (the guardrail on the brownfield path), each older blocker and upstream note rechecked at 0c726f5, and the observed end state labelled as the release-1.0.3-hotfix run. docs/platforms.md, docs/intel.md and README.md: eat-up.sh deploys release-1.1.0; the path is pre-registered as F4 and has not run; the ledger rows that pinned EAT stock at 0d3438d use their own checkouts and image tags, so the move changes none of them.
…1.1.0 turn it on With no deploy_guardrails value in the config, release-1.1.0 deploys its Qwen3Guard guardrail: deploy-agentic-stack.sh:195 defaults DEPLOY_GUARDRAILS to on and brownfield.sh keeps that default. Every config written for release-1.0.3-hotfix lacks the key, so an EAT_CONFIG carried over from the previous pin would bring up the guardrail (a 2 CPU / 16Gi vLLM pod whose image guardrail-values.yaml names by tag only, screening every gateway request) while the docs say the guardrail is off. eat-up.sh now stops before touching the cluster when the config gives deploy_guardrails no value, read the way read_config_file reads it, and asks for off or on. The shipped agentic-config.cfg sets it off, so F4's path is unchanged. openshell_setting becomes cfg_value <cfg> <key> for both checks. tests/eat_test.sh 3c covers a missing key, an empty value, a commented-out line, another key that mentions it, last assignment wins, and off, on and a quoted value passing.
… STOP names the change that broke the hunk Three gaps in the auto-drop logic, each found with a synthetic tree on the fixtures and each now a failing-then-passing case in tests/eas_test.sh: - The 0006 Exists probe checked for the exact "" control-plane selector only in the file it matched, and only with an unquoted key. An Exists term in another file of roles/envoy_gateway, or a flow-style selector with a quoted key, gave drop-fixed while the EnvoyProxy kept the selector that matches no k3s node. A probe can now carry an `absent` regex that no file under its glob may match; 0006 uses it for the selector in any quoting, role-wide. - The vars/k3s.yaml probe for the EAS #50 layout matched any _envoy_gateway_proxy_shape, including controlplane_daemonset, the shape that carries the exact "" selector. It now matches only another shape; a k3s entry that keeps controlplane_daemonset is still the STOP naming #50. - A STOP named a `moved` hint whenever its regex matched anywhere, and otherwise the last commit on any of the patch's files. Once EAS #61 merges, every later 0002 STOP would have named #61. A hint now counts only when it watches a file whose hunks no variant applies (git apply --check --include), and the fallback names the last commit on those files. The test helper that reads the decisions JSON now removes it before each run. Before, a run that wrote no JSON left the previous run's decisions in place, and two checks passed with --rev or kubelet-static broken outright. Decisions are unchanged at both pins (main 97f6157, release-1.2 5c27fb3) and at every open EAS pull request head, checked on a fresh clone.
fit sizes the KV cache for its own context, the --max-model-len in its flags (32768 at most). The generator takes only VLLM_CPU_KVCACHE_SPACE from fit, and EI's catalog sets no --max-model-len for qwen2-5-coder-14b, qwen2-5-coder-7b or llama-3-1-8b, so vLLM serves the model's own context. Llama-3.1-8B-Instruct's is 131072 tokens (max_position_embeddings), which at 128 KiB a token needs 16 GiB of KV cache for one request. vLLM v0.28.0 sets the KV cache from VLLM_CPU_KVCACHE_SPACE (vllm/platforms/cpu.py#L165-L169 at 2cf0a69) and will not start when one request at max_model_len does not fit it (vllm/v1/core/kv_cache_utils.py#L747-L767). The fit-missing and rootless-docker goldens pick llama-3-1-8b with an 8 GiB KV cache, which vLLM refuses. The four goldens that lower the KV cache now also carry fit's --max-model-len, as args_append on the model's entry in models.edit.yaml, with a choice line citing vLLM's check. The config section checks that every lowered KV cache has one, that the value comes from fit (16384 in a mutated fit document), and that a fit document with a KV cache and no --max-model-len exits 2. EI's NFD role skips the install only when it finds a Helm release named node-feature-discovery (roles/nfd/tasks/install.yaml#L15-L25 at 3e8a244). NFD's own docs install it as release nfd in the same namespace (docs/deployment/helm.md#L41 at kubernetes-sigs/node-feature-discovery b8c0974). The generator called any Helm release EI's own and kept nfd_enabled: true, so EI would install a second NFD next to it. The new check expects nfd_enabled: false for release nfd. Config section: 116 passed, 20 failed, each on these cases. The overlay section passes (87).
… only by name When k3d-gpu fit lowers a model's VLLM_CPU_KVCACHE_SPACE below the catalog's 40 GiB, the generator now also writes the --max-model-len fit sized that cache for, as args_append on the model's entry in models.edit.yaml, with a choice line citing vLLM's check (vllm/v1/core/kv_cache_utils.py#L747-L767 at 2cf0a69). Without it EI's catalog, which sets no --max-model-len for these models, leaves vLLM on the model's own context: 131072 tokens for Llama-3.1-8B-Instruct, 16 GiB of KV cache for one request, so an 8 GiB cache from fit stops vLLM v0.28.0 at startup. A fit document with a KV cache and no --max-model-len is malformed input (exit 2): fit's vLLM CPU flags always carry both (console/fit.py _flags). nfd_enabled stays true only when the NFD DaemonSet belongs to the Helm release node-feature-discovery, the one name EI's NFD role checks before it installs (roles/nfd/tasks/install.yaml#L15-L25 at 3e8a244). NFD from a Helm release of another name, such as nfd from NFD's own docs, now gets nfd_enabled: false, as k3d-gpu's baked NFD does. The docstring states how models.edit.yaml merges: defaults merge, entries match by name, env merges and args_append goes after the catalog's args. tests/eas_test.sh: 223 passed (overlay 87, config 136). ci_wiring_test.sh 70, eat_test.sh 64 and image_pins_test.sh 43 pass; claims_check.sh is clean and ledger_drift_check.py agrees; shellcheck v0.11.0 is clean.
… 200 items in H54q Re-grading every arm's 200 items from the raw records (h54.q_state over hold1/R, hold1/OVQ, hold2/OVB, hold2/Lg and H54a's imported items 0-49) finds that items 85, 119 and 187 defeated all four arms. Item 182 did not: OVB answered it (hold2/OVB/items.jsonl, idx 182, ok true, gold 23). The row's result text and the run section said R, OVQ, OVB and Lg answered all 200 items in holds 1 and 2. Only R did; OVQ, OVB and Lg answered items 50-199 there, and their items 0-49 are H54a's records (Q1 item 2), as the method column, the What ran table and the Disclosed bullet already state. No count, test, CI, prediction or verdict changes.
# Conflicts: # EXPERIMENTS.md # README.md # docs/intel.md # docs/platforms.md
# Conflicts: # docs/intel/technical-report.md
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
88plug
added a commit
that referenced
this pull request
Oct 30, 2026
A ledger line listed only the rows whose ledger sections name its path, so a runner another row runs or imports turned historical when its own rows finished while the reusing row was still PENDING. #262 landed the H57dp and H57de verdicts and bench/h57d/** went historical while wildct's H57w rows still run it through bench/wildct/row.sh; the guard then refused #268's H57d amendment R2 edit of bench/h57d/arm.sh as a historical edit. A scan of every ledger runner's code for the bench/ paths it calls found the reuses, and each line now lists the reusing rows and their amendment prefix: bench/h57d (the H57w rows; h57d.py also H59), bench/h54/h54.py with its tests and GSM8K items (H59, H60), bench/prefill-guard's cpufreq.sh and prompt.txt (H55), crescent's serving.py (the cross-host rows, H60, H59), bench/xhost/fetch_models.py (the wildct rows), bench/load (the desktop, crescent and cross-host rows and H59w) and bench/shared-prefix (H59). The rest of each tree keeps its own rows, and the H57dp and H57de records get their own historical line now that the H57d tree is an arm again. tests/pin_classes_test.py checks each reuse: the reusing file still names the path, the path's line lists the row, and the path is an arm while the row is PENDING.
88plug
added a commit
that referenced
this pull request
Oct 30, 2026
The base branch claude/eas-eas-config landed on main in #262. The one conflict was the header comment of tests/eat_test.sh, which now lists both the EAS mode checks from this branch and main's deploy_guardrails refusal.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lands six reviewed PRs in one merge, with one CI run for all of them. Each constituent is merged with --no-ff, so its commits keep their own history.
Order: code and infra first, then docs, then ledger results.
Integration changes made in the batch:
Local checks on the batch head: every suite in .github/workflows/ci.yml that runs without extra tooling, the simulated hardware matrix, the agent examples, tests/claims_check.sh and tests/ledger_drift_check.py.