[88plug]

integrations/eat/eat-up.sh now deploys EAT release-1.1.0 at 0c726f5 instead of release-1.0.3-hotfix at 0d3438d. release-1.1.0 (published 2026-10-22) is still EAT's latest release and latest tag on 2026-10-29 (gh api .../releases, git ls-remote --tags). The compare is 18 ahead, 0 behind, 204 files. This is the EAT 1.x part of the EAS plan. It does not depend on the EAS parts.

Not verified. Nothing here has run against a cluster. The user path on the new tag is pre-registered as ledger row F4 (PENDING), committed first in this branch, before any run. No doc says the release-1.1.0 path works; each says it is F4 and not yet run.

What changes

• eat-up.sh: EAT_TAG=release-1.1.0, EAT_COMMIT=0c726f576595971c53cc45b94e08ba969beb4a4a.
• agentic-config.cfg sets release-1.1.0's new toggles to off: deploy_guardrails, deploy_vllm_sr, deploy_openshell, deploy_kata_containers, deploy_ceph and rack_scale_mode.
• brownfield.sh passes the config's deploy_guardrails to EAT's DEPLOY_GUARDRAILS before it sources deploy-agentic-stack.sh. The config key alone would not stop the guardrail (see "Two corrections" below).
• vllm-values.yaml pins vllm/vllm-openai-cpu:v0.28.0@sha256:197354e6475e638eb5ccca09beb078488046a82de0e204e7429bf1a804df9647. That is the tag release-1.1.0's xeon-values.yaml:34 names. The digest is the one crescent amendment E1 recorded, and scripts/images-lock digest returns the same value today. images.lock changes only that entry.
• The deploy_openshell=on refusal used to say the tag has no OpenShell role. It now gives the real reason: OpenShell ships in release-1.1.0 but has never run on a k3d-gpu cluster.
• Docs: integrations/eat/README.md (the pin, a pins table, the 1.1.0 gateway, blocker 11, the old blockers and upstream notes rechecked at 0c726f5, and the observed end state labelled as the 1.0.3 run), docs/platforms.md (the EAT section, including the stale lines 233-238), docs/intel.md and README.md.
• bench/eatflow pins are untouched. The ledger rows that pinned EAT stock at 0d3438d use their own EAT checkouts and set their own vLLM tag (H50, H50o and H51 under E1, H7x under V1, H7 and H8 in bench/apb/h7.sh and arm.sh). The move changes none of them, and bench_test.sh still passes.

Two corrections to the plan, from EAT's source

1. The guardrail ignores deploy_guardrails on the brownfield path.

   • Write_config is not the cause. It only runs from main(), which the sourced brownfield run never reaches.
   • deploy-agentic-stack.sh:195 sets DEPLOY_GUARDRAILS="${DEPLOY_GUARDRAILS:-on}" at source time.
   • Only main() (:1136-1140) copies deploy_guardrails from the config into it.
   • fresh-install.sh:419 deploys Qwen/Qwen3Guard-Gen-0.6B when DEPLOY_GUARDRAILS is on.
   • No other line in the tree assigns it.

   So brownfield.sh reads the key the way read_config_file reads every other toggle: trimmed, quotes dropped, last assignment wins. It then exports DEPLOY_GUARDRAILS, and with no value EAT's default stays.

2. Dropping _auto_skip_deployed_components changes nothing for eat-up. At 0d3438d it was called only from run_deployment (deploy-agentic-stack.sh:783), which only main() calls (:1133). eat-up's path never ran it.

Review of 0d3438d...0c726f5 against brownfield.sh, gateway-charts.py and gateway-values.yaml

core/playbooks/setup-bastion.yml

• Both pip tasks now pass --break-system-packages (:73, :171). The bastion's /etc/pip.conf line is now redundant but harmless, and it stays.
• The kubectl (v1.29.0) and Helm (v3.14.0, creates: /usr/local/bin/helm) tasks are unchanged, so the baked Helm still skips get-helm-3.

core/playbooks/deploy-agent-sandbox.yml

• The only change is retries (5 tries, 30 s apart) on the sandbox_router.yaml download.
• agent-sandbox is still v0.5.0 (agentic-metadata.cfg). The router, its auth Secret and the warm pool that eat-check.sh uses are unchanged.

core/lib/user-menu/parse-user-prompts.sh

• --compute_platform used to set cpu, which was a bug; it now sets compute_platform.
• prompt_for_input auto-enables NRI balloons only when compute_platform is c and deploy_nri_balloon_policy is empty.
• Our config sets the policy off, so the "Proceeding" branch runs as before. compute_platform defaults to cpu (config-vars.sh:16).
• core/lib/brownfield/ has no diff, so the menu answers 5 / 1 / yes still hold.
• Every function brownfield.sh calls is still defined:
  • _source_core_libs at :631
  • DEPLOY_SOURCED at :1188
  • manage_kubeconfig, read_config_file, prompt_for_input, setup_initial_env, setup_bastion and deploy_inference_llm_models_playbook
• deploy_inference_llm_models_playbook still passes xeon_values_file=${xeon_values_file_path}, so the merged values still reach the playbook.

core/helm-charts/genai-gateway

• customRouter.enabled: true mounts the router's Python from a new ConfigMap, genai-gateway-router-code (templates/router-configmap.yaml).

• litellm_settings.callbacks gains custom_hybrid_router.proxy_handler_instance.

• The config moves to /app/proxy_config.yaml through a subPath mount. A ConfigMap edit therefore reaches LiteLLM only after a pod restart, and eat-remote.sh already restarts the pod.

• A policyPlane block was added; it defaults to false.

• No new image and no Chart.yaml change.

• gateway-charts.py runs clean on the 1.1.0 charts and keeps customRouter and the callback. eat_test.sh now checks both.

• Rendered with helm template (Helm v4.1.1 here, the same dependency charts and values on both sides), the copies differ from EAT's charts only in 11 image: lines: 4 in the gateway, 7 in Langfuse. Every one of them is name:tag@sha256.

• The restore job's bitnami/kubectl:latest stays behind restoreJob.enabled: false.

• The callback should load in the pinned LiteLLM v1.83.14-stable.patch.2 (b36fb1d). Every name it patches or imports exists there:

  • Router._is_auto_router_deployment (router.py:6823)
  • _add_deployment (:7235)
  • async_pre_routing_hook (:9902)
  • the ComplexityRouterConfig, ComplexityTier and DEFAULT_*_KEYWORDS names in router_strategy/complexity_router/config.py

  This is read from source, not run, and it is one of F4's named risks.

• The Langfuse values change only telemetryEnabled (to false), which the overlay does not touch.

core/helm-charts/vllm

• The image moves to v0.28.0, and the pod gains fsGroup: 1001.
• memoryLimit is a separate value that defaults to memory, so ours (16Gi) is still the limit.
• The PVC drops storageClassName: local-path. k3s's default class is local-path.
• cpu falls back to the model config only when it is unset; ours sets "8".

deploy-inference-models.yml

• cpu-qwen3-1-7b is still in 1.1.0's model list (install-cpu-qwen3-1-7b, lines 826-911). Qwen/Qwen3-1.7B is still a modelConfigs key (xeon-values.yaml:193, KV 40).
• The new sizing role and the balloon-only --set lines are gated on balloon_policy_cpu == 'enabled', which is off here.
• It is still missing from get_model_names (model-selection.sh:106), so eat-up.sh model <id> is still needed (blocker 8).
• eat-opt.py runs clean on the real 1.1.0 playbook and merged values. It reads vLLM 0.28.0, keeps EAT's hermes parser, adds --reasoning-parser qwen3 and thinking off, and chooses no speculative config before v0.31.0.

vLLM v0.28.0 itself

• It no longer reads VLLM_CPU_SGL_KERNEL. vllm/envs.py defines it at v0.24.0 and not at v0.28.0; the change is vllm-project/vllm#50801.
• Whether it serves Qwen3-1.7B on the AVX2-only i9 is F4's other named risk.

Ledger: F4 (PENDING)

• What it is. H1b's user path on release-1.1.0 on the i9-13900T, on one fresh cluster k3dgpu-f4-eat.
• Steps.
  1. k3d-gpu up with the README's EAT env
  2. eat-up.sh
  3. eat-up.sh model cpu-qwen3-1-7b
  4. the readiness wait (--field-selector=status.phase!=Succeeded, 30 min)
  5. eat-check.sh
  6. k3d-gpu down
• Scope. n = 1, functional.
• Grading. SUPPORTED needs steps 1-4 to exit 0, and eat-check.sh to pass the chat, the get_weather tool call and the sandbox's 385.
• Prior and risks. P(SUPPORTED) = 0.6. The named risks are the hybrid-router callback (0.15) and vLLM v0.28.0 on AVX2 (0.15).
• Where. The row and its pre-registration section are in EXPERIMENTS.md.

Coordination

• Latest tooling pins (2026-10-29) and crescent amendment E4 #238 changes only the Prometheus entry in images.lock, near line 405. This branch changes the vLLM CPU entry, near line 277. git merge-tree with Latest tooling pins (2026-10-29) and crescent amendment E4 #238's head is clean, and so is ledger(H54q): INCONCLUSIVE on the Xeon 6741P; runner amendment Q2 and the run #243.
• Rebase. The branch is rebased on main e5748cd1 (after docs: state what ran on the Xeon 6741P instead of "simulated sysfs only" #246). The one conflict was docs/intel.md's planned list: docs: state what ran on the Xeon 6741P instead of "simulated sysfs only" #246's hardware-coverage bullet (H52 and H52b REFUTED) is kept as main has it, and this branch's "EAT 1.1.0 run" bullet replaces main's "EAT 1.1.0" bullet, which said the move waits until no pending ledger row pins 0d3438d. Those rows use their own EAT checkouts (see "What changes").
• W13 and W14. Neither workflow has a branch or PR on origin (rechecked 2026-10-29 14:30 PDT). W14 has an unpushed local branch, claude/agentstack-eat-release-1-1-0, that also moves eat-up.sh to release-1.1.0, as an EAT_RELEASE opt-in with ledger row H1c. It touches the same files, so whichever lands second rebases onto the first and drops the duplicate pin.
• Branch name. The branch name follows the sibling EAS parts' eas- prefix.

Checks run (all pass)

Check	Result
tests/eat_test.sh	76 passed (16 failed before the change, for the expected reasons)
tests/detect_test.sh	1185 passed
tests/reserved_cpus_test.sh	23 passed
tests/bench_test.sh	71 passed
tests/image_pins_test.sh	43 passed
scripts/images-lock check and scripts/images-lock pins	ok
tests/platforms_doc_test.sh	195 passed
tests/ci_wiring_test.sh	69 passed
tests/claims_check.sh	26 files clean
tests/ledger_drift_check.py	41 files agree with 81 rows
shellcheck v0.11.0, severity warning (CI's version and level)	clean on eat-up.sh, brownfield.sh, eat-check.sh, eat-remote.sh and eat_test.sh
Docs build, CI's pinned python:3.14.8-slim, hash-locked toolchain	tests/docs_test.sh 63 passed; mkdocs build --strict clean

Not verified

• No cluster was run.
• The guardrail hand-off was checked against a stub that reproduces EAT's line 195. The real script was not sourced here, but a grep shows no other assignment of DEPLOY_GUARDRAILS in 0c726f5.
• These are read from source and are F4's job:
  • Helm v3.14.0 rendering the 1.1.0 charts (only v4.1.1 was used here)
  • the router callback loading at runtime
  • vLLM v0.28.0 on this CPU
  • the new NUMA-aware utils tasks never running with balloons off