Skip to content

docs/FEATURES.md said routed-expert streaming was CPU-only after W0c/W0d made a staging device take the slot arm, and the doc-checkpoint gate caught it one commit too late to repair #1387

Description

@localai-bot

Found while repairing the fresh review of #1377 (row ENG-EXPERT-STREAM-DEVICE, issue #1124).

What is wrong

Two things, one cause.

The projection was stale. docs/FEATURES.md's "Routed-expert weight streaming from disk" row read "CPU keep-quant towers only". W0c changed that: the seam takes the slot arm on is_cpu() || host_memory_is_device_addressable(), so a staging device whose kernels can dereference host storage takes it too, and W0d made the load-time fit refusal drop those towers from its bound. AGENTS.md routes exactly this to docs/FEATURES.md — "a feature, model, backend, or quantization surface changes" — and the change that moved the surface did not write the page.

The gate said so and could not be obeyed. scripts/check-doc-checkpoint.py fails commit 939755f99 of row/ENG-EXPERT-STREAM-DEVICE-W0: "changed .agents/benchmark-record.md: measurement recorded but did not update docs/FEATURES.md". The checker walks the range one COMMIT at a time (main(), the --base/--head arm), so once a commit is published on a branch that may not be force-pushed, no later commit can make that commit green. The repair below writes the page, which makes the SQUASHED commit on main carry both paths, but scripts/agent-preflight.sh on this branch keeps reporting doc-checkpoint range red until the branch merges.

What was fixed in flow

The FEATURES.md row now says "keep-quant towers only (#1378); ... CPU, plus a host-readable staging device (#1124)". The cell budget is 220 characters and the old cell was exactly at it, so the observability detail it used to carry ("One [expert-stream] line on a clean exit IF a store existed") moved out; it is stated at docs/USAGE.md:4598-4620 and in .agents/specs/expert-streaming.md, which is where the page's own legend sends a reader for caveats.

What is NOT fixed, and the decision it needs

Whether a per-commit record gate should be satisfiable after the commit is published. Today it is not, and the only remedies are a force-push (forbidden) or living with a red until the branch merges. Two shapes are worth considering and neither is obviously right, so this is filed rather than decided: evaluate the range as one aggregate diff when the caller asks for a range, which is what a squash merge actually lands; or keep the per-commit walk and say in the message that a later commit in the same range satisfies it. Owning row ENG-EXPERT-STREAM-DEVICE for the record half; the checker semantics half needs its own row and spec per AGENTS.md "Changing the rules or a checker".

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions