2026-10-28 — Model-matrix step 2 (itd-2610161733316518, spc-2610161949559050) derives each cell pin's source (host, openrouter, local or provider) from the cell's parsed route and refuses a pin whose source disagrees with it, because step 1's pinCells takes the source as given and a provider route pinned as host would skip the spending-cap and provider-pin checks (decisions 6 and 17). Step 1 cannot check it: the route grammar is parsed only where the run starts, in step 2. Found by the step 1 review pair.

Frontmatter

.abcd/work/decisions/dcn-2610280629294458-model-matrix-step-2-itd-2610161733316518.md
open on GitHub ↗ · commit history ↗

mentions3

• dcn-26102808524716252026-10-28 — Model-matrix step 2 (itd-2610161733316518) builds dcn-2610280629294458 in two halves: a run starts only from a plan whose every cell source resolveCell derived from the cell's parsed route and this machine's provider configuration, consented to by its digest; and the run record's pinCells refuses a pin that disagrees with what the route itself fixes (the host leg pinned host and nothing else, a runner route on its own runner and <provider>/<model>). A claude-runner cell is a runner route like any other and names its model: the claude runner runs bare on its API key, so it spends and is never the host, which runs in the host's own harness (decision 10). pinCells does not re-read the provider configuration to tell openrouter, local and provider apart: that split is the configuration's, the plan already reads it, and the plan's digest binds the person's consent to what it read. Grounds: the named risk, a provider route pinned as host skipping the spending cap and provider-pin checks, is the host/route disagreement the record now refuses.
• itd-2610161733316518One task done across a model matrix, re-runnably
• spc-2610161949559050a-product-thinker-who-wants-to-know