lane pin from the settings sheet: three turns served by another machine while the chip read @morph (seen once, dev 649392ad7) #1022

What happened

Driving dev @ 649392a on Spark (real OpenRouter key, moonshotai/kimi-k3, routing: simple), Morph was pinned through Settings → Providers → lane → fold → enter. The lane row read • pinned: Morph, config.json held "lane.talk":"Morph", and the status chip read moonshotai/kimi-k3@morph. The next two turns in that process, and the first turn of the process relaunched right after, were answered by Sail Research (calls.jsonl: "served":"Sail Research","status":200). A body carrying {"only":["Morph"],"allow_fallbacks":false} cannot be answered by another machine, so for those three turns the pin was not on the wire while the chip said it was.

Five later sequences (pin mid-session, pin at launch, with and without AFORGE_DEBUG=1) all carried the Morph demand and were served by Morph. Not reproduced. Those three turns have no request-body record because AFORGE_DEBUG=1 aforge wrote only run.json and no calls/ (see the papercut below).

Suspects, unverified: the chip is drawn from the profile row (laneNow → config.LanePinned) while the wire asks the transport (provider.PinnedFor), which drops a pairing the wire has retired in this process; a retirement of Morph for kimi-k3 earlier in the same process would give exactly this screen. But the relaunched process's first turn was also served by Sail Research, and retirements are in-memory, so that alone does not explain it. app.pinnedNow() keying by the surface's model spelling vs the wire slug (noted on #1019) is the other candidate.

Replication a stranger can run

Spark, any home under the socket path limit:

AFORGE_HOME=/tmp/srp AFORGE_PROFILE_DIR=/tmp/srp aforge chat --debug     # writes request bodies to logs/trace/<run>/calls/
# ctrl+, → Providers → lane → enter → walk to morph → enter; send two turns; quit; relaunch; one turn
# compare provider objects in calls/*.json with served on calls.jsonl and the chip on screen

Evidence of the one occurrence: spark:~/af-sr-settings-evidence/ (folder for step 4, SUMMARY.md).

Acceptance

End to end first: with the lane row reading pinned: Morph and the chip reading @morph, every request body of that process and of the next launch carries {"only":["Morph"],"allow_fallbacks":false}, asserted on calls/*.json; or, if the transport has retired the pairing, the chip does not say @morph and the retirement sentence is in the conversation. Then a unit law: the chip and provider.PinnedFor read the same fact.

Papercuts found on the way (same drive)

• Nothing in the settings sheet says a routing change lands on the next session; the lane row keeps explaining itself in the launch routing's words on the same screen where routing already shows the new word.
• AFORGE_DEBUG=1 aforge wrote only run.json, no call bodies, in four launches; aforge chat --debug writes them. internal/manual/chat/debug-record.md advertises the env var.
• The lane fold has no "back to auto" gesture (clearing is ~16 ↑ presses past every lane, and one too many lands on another model's row where enter switches model); the filter box filters models, not lanes.

🤖 Generated with Claude Code

https://claude.ai/code/session_0182eyxXP8Xe7ADNKpYDe4wv

Drafted with CodeAF · reviewed and owned by the author