feat(e2e): read the Architect's "drop list" instead of discarding it

[sdubagun-amd]

The problem

When GEAK starts a run, one of its agents — the System Architect — reads the GPU profile and
decides what to work on. It produces two things:

1. a work list: the kernels worth optimizing, and
2. a drop list: kernels it looked at and rejected, each with a reason
   ("below Amdahl threshold", "too small to move e2e", and so on).

GEAK has always acted on the first list and thrown the second one away. Nothing reads
it — not the orchestrator, not a log line, not a report, not another
agent's prompt, not the saved state that survives a resume.

So the planner identifies the wasted work, says so out loud, and then the run goes and does it
anyway. In the 15-hour Qwen3-14B-FP8 baseline the string drop_list appears zero times in the
entire run tree. It was written and immediately discarded.

What this PR changes

GEAK now reads that list.

Concretely: there are three points in a run where the work list gets set — when the Architect first
plans, when a run resumes from saved state, and again after the config sweep, when the Architect
re-plans with fresh information. Each of those three places used to just take the agent's output
as-is.

This PR puts a single shared cleanup step in front of all three, a function normalizeQueues.
The cleanup step does three things, in this order:

First, make sure every kernel can be referred to

A drop entry says "skip this one", which only works if both lists agree on which one. The
Architect returns each candidate as a free-form JSON object and the schema requires no fields at
all, so a candidate can arrive as just {"short_name": "rmsnorm", "pct_gpu_time": 2.0} — with no
identifier. For those we fill in a positional stand-in (h0, h1, k0, …) so every candidate has
a handle for the rest of the run.

We also record that we invented it. An id GEAK assigned is not something the Architect could
ever have written down, so a drop entry naming h3 must never match a candidate whose h3 we
made up.

Second, re-apply the fused-kernel protection

A Mixture-of-Experts layer routes each token to a few of many small expert matrices. A fused MoE
kernel does all of that in one GPU launch. GEAK has a rule that one of those must never be treated
as an ordinary dense matrix multiply. In code the rule does two things: it tags the candidate as
moe, which stops GEAK generating a dense matrix-multiply benchmark for it, and it holds onto the
Python function where the fused kernel is actually called, which is the only place a replacement
can be installed. A dense matrix multiply has no such call site — so a fused kernel mistaken for a
dense one ends the run with a result that cannot be installed anywhere.

Why it needs to survive a re-plan. Of the three points where the work list is set, this rule
used to run at only the first. After the config sweep the Architect re-plans, and the code
replaced the whole work list with brand-new candidate objects that had never been through the
rule — tag gone, call site gone, nothing to re-apply them. Moving the rule into the shared step
means all three points get it: first plan, resume, and re-plan. That is bug 1 below.

Third, apply the drop list

Match each rejected entry against the work list and remove it — but only when the match is
unambiguous and the drop is justified, which is the next section. If the entry carries the
Architect's own identifier we match on that and nothing else. If it does not, we fall back to the
kernel's short name, or to the Python function GEAK would have to swap out to replace it (written
as module:function) — whichever the agent gave us.

The drop_gate setting

The default is on. Merging this changes what runs do.

setting	what happens
on	Kernels the Architect rejected are removed from the work list, provided the drop passes all four checks below. Default.
off	The drop list is ignored entirely.

The first two steps above — filling in identifiers and the fused-kernel protection — run in
both settings. They are bug fixes, not part of the gate.

What makes on safe as a default

A drop is refused unless all four of these hold. Every refusal is logged with the Architect's
own stated reason, saved into the state that survives a resume, and counted in a one-line summary
at the end of the run.

1. Exactly one match. If the entry carries an identifier, it is matched on that identifier
   alone — no falling back to the name. Otherwise a stale or hallucinated identifier would miss,
   then quietly land on some other kernel by name. An entry that matches two kernels is refused
   rather than guessed at; a drop is not reversible.

2. A known size. The entire argument for a drop is "too small to be worth the time", so a
   kernel whose GPU-time share we cannot read is one we cannot justify dropping. This is worth
   spelling out because the obvious code is wrong here: Number(x) || 0 turns a missing field into
   0% — the single most droppable value there is — and would walk straight past check 3. Missing,
   blank or unparseable is refused. An explicit 0 is a real measurement and is allowed.

3. Under 30% of GPU time (HEAD_PROTECT_PCT). The dominant kernel in the profile is never
   dropped on an agent's say-so.

4. The list is not eating the queue. A drop list resolving to more than half the work list
   (DROP_MAX_FRACTION) is refused whole — not half-applied in arbitrary order. At that size the
   useful signal is "the plan is wrong", not "here are some kernels".

A drop entry that matches nothing is logged loudly and recorded too. A silent no-match looks
exactly like a filter that is working.

Three bugs fixed along the way

These are independent of the setting above and are fixed in both settings.

1. A re-plan silently dropped the fused-kernel protection. The rule that keeps a fused
   Mixture-of-Experts kernel intact ran only after the first plan. The config sweep's re-plan
   replaced the work list with fresh, untagged candidates and the rule never ran again. Its own
   comment in the source says a fused kernel "is never SKIPPED" — after a re-plan, it could be.

2. Only fused kernels got wired to their call site. The same loop that applied the fused rule
   was also the only place that recorded which Python function to swap out for a kernel, and it
   skipped everything that was not fused. Now every candidate that has one gets it.

3. The work list was copied shallowly. .slice() copies the array but not the objects inside
   it, so later steps were writing into the Architect's own returned objects, and those edits were
   being saved into the state that survives a resume. The shared step now takes a deep copy.

Tests

e2e_workflow/scripts/test_drop_gate.js pulls the real cleanup function out of the orchestrator
source and runs it against a synthetic work list. 54 assertions, covering:

• off is inert, and on is the shipped default;
• a 57%-of-GPU-time kernel on the drop list is refused;
• a kernel with a missing, blank or unparseable GPU-time share is refused, while an explicit 0
  is allowed through;
• an entry that carries an identifier does not fall back to the name when that identifier misses;
• an identifier GEAK invented cannot satisfy a drop entry;
• an entry matching two kernels drops neither;
• a drop list covering 4 of 6 candidates is refused whole, while one covering exactly 3 of 6 applies;
• matching on the call site ignores the argument list;
• the agent's own objects are not mutated, and running the step twice gives the same answer
  (which a resume or a re-plan does);
• all three work-list assignments go through the shared step.

🤖 Generated with Claude Code and edited manually.