[MerciHanrim]

v0.28.2 — a resource port's connections on two sides branch on their own

The router grouped a port's connections into one fan by node and handle id only, so an out leaving a node's bottom face and one leaving its right face shared branch points and excused each other's stub (Coffee's green wholesale line had a needless S-jog from it). Share notes 50 and 54 hold the investigation, the experiments and every same-view capture. Three commits, each verified as it was done.

1. The rule (5364fca, src/store/routeMap.ts)

A new fanKey decides, per FAN:

• fan membership (branch points, first legs): for a RESOURCE port the node, the handle id and the face — two sides are two stubs in two places, two fans; a STATE port keeps one fan across its sides, as before;
• the sibling relation while routing: a sibling's route is cut at the shared stub (not charged there) and offered as lanes, anything else is an ordinary obstacle — so two resource lines on two sides of one handle no longer excuse each other's stub; and the fanOverlaps check.

endKey still decides, per handle: the port use behind "no label on a shared stub", a route's exemption from its own ports' reserved stubs, and the parallel sets. A resource in and out are never one fan. docs/edge-routing.md §ER14.3 says which connections form one fan and what each key decides.

Why state ports are not included. Grouping every port by side was measured first: it fixes Coffee the same way but makes three lines harder to follow on the gacha banner Template. Reverting one port at a time showed all three are one thing — an arriving and a leaving state connection meeting one side of a node at one point, which the old cross-side fans happened to push apart. That meeting is a separate, later unit. A general cost for running beside another line was tried for it and rejected (it fixed none cleanly, broke Coffee's roasted-bean fan, slowed MMO routing about 60 %).

Why the sibling relation follows the fan. Measured on 32 small synthetic diagrams with one handle used on two sides: 29 draw the same either way; in the 3 hard ones (an in fed from straight left into its top side and from straight above into its left side) treating the two as siblings let one hook round the corner across the other — 2–3 crossings; as ordinary routes, 1. None worse.

2. What draws differently

Every bundled example dumped in the browser: Coffee roastery operations flow 1 route (e_green_wholesale, straight now), 3-zone gacha banner comparison 5 (e_pickup_3, 4, 5, 9, 14: same-view close-ups judged three easier to follow, two no real difference), every other example unchanged; the router's fan diagnostics 0 / 0.

3. Tests

src/store/routeMap.fanKey.test.ts (9), through a test-only seam __planFans (not on the dev bridge; absent from the production build): resource ports by face, state ports across faces, in / out never one fan, and the three hard cases (one crossing). Mutations: the face dropped from the resource key fails the two resource-by-face tests, the face added to the state key fails the state test, the sibling relation on endKey fails the three hard cases.

4. Baseline (0e84f70) and release (b5e2bdf)

• One screenshot baseline changed, as expected: forced-active-resource-coffee-z05.png (29 px, the straightened Coffee line), regenerated from the final code; byte-identical to the reviewed "actual".
• 0.28.2: .changes/fan-key-by-face.json (user-facing), three What's new lines in 18 languages (resource connections on two sides branch separately in some diagrams; six automatic routes in two bundled Templates change, named by each locale's own Template names; state connections unchanged), CHANGELOG v0.28.2, README Latest. Release date 2026-10-15, to be checked on the merge day.
• The translation contract tests pass: evidence of the catalogs' structure and terms, not a review of how the lines read. The English and Korean lines were reviewed; the other 16 had no native-speaker review.

Verification, by head

Head	What ran	Result
b5e2bdf	PR CI, run 38667880094	success: checks, e2e shards 1–6, production bundle, PWA
b5e2bdf	Full local e2e, --workers=1 --retries=0	2 191 passed, 0 failed, 10 skipped (47.9 min)
b5e2bdf	dist config, then pwa config, run separately	16 passed; 19 passed
b5e2bdf	Unit (vitest, full); tsc; lint; check:change-declaration, check:i18n, check:i18n-surface, check:control-bytes, check:isolate-arguments, check:locale-lists, check:functional-glyphs, check:e2e-shards, check:snapshot-policy	3 586 passed, 1 skipped; lint 0 errors; all pass
0e84f70	forced-colors-edge-tell.spec.ts without updating	19 passed

An earlier full run on b5e2bdf stopped at test 272 of 2 201 with no failure reported, when the session restarted; it is not a result and was rerun from the start (above).

Separate, later units

The arriving / leaving state connections at one point of one side (Pity top, Roll — forced, owed bottom on the gacha banner) — why the state half of the face rule waits. Seen while measuring, main too: after undo / redo React Flow keeps a connection's selected mark without the Inspector's selection; starting to draw a connection on the gacha banner costs about 0.2 s (636 face handles mount).