workflow-fix: verify_plan c26/c27 routed-machine mirror is GCP-era, inverts under runpod-first auto default
Highlight text on any card (body, plan, or an event) to anchor a comment, or leave a whole-task comment here. Mention @claude to summon a reply.
No comments yet.
Goal
Rebuild verify_plan.py's routed-machine mirror (_C26_INTENT_GPU, and the c27
sets derived from it) so c26/c27 judge a plan's §9 basis GPU against the machine
the live router will ACTUALLY provision under the runpod-first auto default
(#2054/#2059), instead of the GCP-era A100/L4 families. Then remove the interim
staleness caveat the prose surface now carries.
The drift
scripts/verify_plan.py:4826 — _C26_INTENT_GPU maps intents to GPU families:
"lora-7b": "A100", "lora": "A100", "capture-7b": "A100", "ft-7b": "A100",
"eval": "L4", "debug": "L4", ...
Those are the GCP INTENT_TO_MACHINE families (a2-ultragpu A100-80, L4) —
correct when GCP led the auto chain, wrong now. GCP provisioning is DISABLED
(GCP_PROVISIONING_DISABLED = True, #2028) and the live head is RunPod:
DEFAULT_AUTO_LANE_ORDER == ('runpod', 'fellows', 'nibi', 'fir', 'mila')(src/explore_persona_space/backends/router.py, #2054/#2059) — verified live.- RunPod's intent table (
.claude/rules/pods.md):lora-7b→ 1× H100,eval/debug→ 1× H100,ft-7b→ 4× H100.
So for a bare-auto plan, c26 expects an A100/L4 basis while the router provisions
H100. A plan correctly costed on RunPod H100 trips a c26 WARN; a plan wrongly
costed on A100 reads as clean. The check is inverted, the same way
critic-lens-reference.md item 13's prose was before #2298 fixed it.
Downstream consumer — not a one-dict edit. verify_plan.py:5113-5116 derives
_C27_L4_INTENTS and the non-L4/non-CPU set FROM _C26_INTENT_GPU, so c27 inherits
the same GCP-era premise. Scope both.
Why it matters
c26 is WARN-only, which makes this worse, not better: it emits an EXPECTED-FALSE
warning on every runpod-costed bare-auto plan, and the prose surface now tells
readers to ignore it (see the caveat below). A gate whose documented guidance is
"this warning is expected" is a gate reviewers stop reading — and the day a plan is
genuinely mis-costed, the real WARN is indistinguishable from the noise.
Fix shape (as specified by #2298's implementer when it raised the concern)
- Derive the routed GPU family from the live lane head rather than hardcoding a
provider's table — the same AST-read-the-source approach
workflow_lint.py --check-lane-order-adjectivealready uses to stay in sync (_default_auto_lane_order), so the mirror cannot silently invert on the next lane-order change. Keep it hermetic (no network, no live API call at lint time). - Re-calibrate the corpus: c26/c27 are heuristics tuned against the existing plan corpus, so re-scan after the mapping changes and re-baseline expected findings.
- Update
tests/test_verify_plan.pyc26/c27 coverage (and any c26-derived assertions intests/test_issue2476_gates.py). - Remove the interim caveat at
.claude/rules/plan-compute-sizing.md:804-806("c26's routed-machine mirror is GCP-era and tracked separately — a c26 WARN on a runpod-costed bare-autoplan is expected until that mirror is updated"). Once the mirror is rebuilt that sentence becomes stale prose on the prescriptive surface — i.e. it becomes the exact defect class #2298/#2331 existed to close. Landing the code fix without deleting the caveat just relocates the drift.
Provenance
Raised as concern c26-gcp-era-mirror-stale (severity CONCERN, round 1, by the
implementer) on #2298, and deliberately left out of that diff per its plan's
Part 5: #2298 was itself a workflow-fix task carrying workflow_fix_target:, so its
recursion guard required the companion be NAMED, never auto-filed. It has sat as an
open concern on a completed task since 2026-08-22 with no execution path —
concerns on terminal tasks are never dispatched.
Surfaced again 2026-08-24 while verifying #2331 (an independent duplicate filing
of the same prose drift, archived after #2298 was confirmed to cover its whole
scope). #2331 was not mechanically workflow-fix-bound
(is_workflow_fix_session(2331) is False — its candidate block is an HTML comment,
not a workflow_fix_target: Provenance line), so filing this companion here is not
a recursion-guard bypass.