test(v2): pin the connector mark and the Tools glyph to the same size (TASK-177)

[lilyshen0722]

TASK-177. The two glyphs agreed at 14px by coincidence of two literals in two files, and nothing tested it.

The gap

side	where the 14 comes from
connector mark	size={14} at V2ConnectorsPage.tsx:1078 → MarkGlyph → icons/glyphs.tsx's G (size = 16 by default)
Tools mode glyph	V2ConnectorTools.tsx:157's own local G, width="14" height="14" hardcoded; it never imports MarkGlyph

So the agreement had no shared source. Drop size={14} and the mark renders 16 while Tools stays 14 — the desync v2.css said could not happen.

The pin is the agreement, not a 14

The test renders the page (it mounts V2ConnectorTools at :1545) with one live grant and the Slack row, then compares the two rendered glyphs' width and height attributes. Non-vacuous by construction: both nodes are asserted present and all four attribute reads (width and height on each glyph) are asserted to be digits (a positive control) before the equality — two absent nodes would otherwise satisfy it.

Which number they agree on stays the design's decision. A 14 asserted in one file would have passed through every misreading of this chain tonight (the 300×150 blowout, the wrong G, the 16→14 shrink).

Evidence

mutation	result
none (control)	pass
drop size={14}	red — mark 16 vs Tools 14
V2ConnectorTools.tsx:157 14 → 16	red
strip height from both G components	red — sprint-review's gate finding: with a width-only control both heights are null, and null === null passes
restored	pass

• Full frontend suite: 113 suites / 1009 tests green (CI=true npx jest --watchAll=false --forceExit, node v22).
• npx tsc --noEmit clean.

Comments corrected (the other half of this row)

Three comments asserted a rule that does not exist:

1. v2.css — "it takes the Tools glyph's rule below (14px, gap 6, tertiary…)". The rule below carries no dimensions; it is layout and colour. The 14 is the call site's prop.
2. v2.css — "the mark shares the Tools glyph's rule … so the two rows cannot drift." The sharing does not carry the size, so they could drift; the test above is what stops them now.
3. V2ConnectorsPage.tsx — "The glyph rides .v2-tools__mode's 14px rule (see v2.css)". Same error. Replaced with the prop, the pin, and feat(v2): Connectors and Tools rows in Direction A — marks, one worded act, mono kicker #1782's reason for following the Tools glyph.
4. v2-layout-invariants.test.ts — "its size now comes from the shared rule above plus the glyph's size prop." The shared rule contributes nothing to size.

No CSS declaration, JSX, copy or rendered output changes: comments plus one test. No v2-layout-invariants count change — no third rule mentions __mark.

[lilyshen0722]

CODE GATE: PASS @ 2b3c84bf — sprint-review. Behind 0, author Lily, 4 files / +70 −7. 13 checks pass, Service Tests still running (which is all the BLOCKED / UNKNOWN reflects). npx tsc --noEmit exits 0 with zero output.

This PR implements a recommendation I made, so this gate is written against the vacuity rather than the happy path.

Scope check

All three non-test files are comment-only — v2.css, V2ConnectorsPage.tsx, and the single changed line in v2-layout-invariants.test.ts, which is the // Rule 3: comment rather than an assertion. So "no rendered output changes" holds, and "the count-exactly-2 __mark invariant is untouched" is accurate: no third rule was added and the assertion itself is unchanged.

Mutation — anchors all 1, BASE 60/60, RESTORED clean

mutation	result
drop size={14} at the mark's call site	1 failed / 60 — the TASK-177 test
V2ConnectorTools' local G: width="14" height="14" → 16	1 failed / 60 — the TASK-177 test
mark not rendered at all ({row.mark ? ( → {false ? ()	1 failed / 60 plus one sibling — the presence guard fires

The third is the one I most wanted. The comment claims the waitFor presence assertions stop the comparison passing on two absent nodes; removing the node proves it, rather than leaving it as a claim about the test's own shape.

Finding: the digit control covers width and not height

The test asserts /^\d+$/ on markSvg.getAttribute('width') and modeSvg.getAttribute('width'), then compares both width and height. height has no such control.

Measured: I removed height from both G components — icons/glyphs.tsx's width={size} height={size} and V2ConnectorTools.tsx:157's width="14" height="14" — and the suite stayed 60/60 green. Both attributes read null, null === null satisfies the height comparison, and only the width pair is load-bearing.

One line closes it:

expect(markSvg.getAttribute('height')).toMatch(/^\d+$/);
expect(modeSvg.getAttribute('height')).toMatch(/^\d+$/);

Low severity — it needs a two-file edit to reach, the same class as the residual this test deliberately accepts. But it is exactly the "both sides move together" failure the test was written to prevent, and the comment states the principle ("prove they carry a value at all") while applying it to one attribute of two. Worth the symmetry.

Affirming the design choice, so a later reader does not file it as a gap

The test pins the agreement, not the value: both glyphs drifting to 16 together passes. That is deliberate, and the test comment says so — "whichever number the design lands on, both glyphs must carry it. The absolute size stays the gate's decision, not this test's."

I recommended that shape and still think it is right. A 14 asserted in one file would have passed through every misreading of this chain in the originating thread, mine included: I read icons/glyphs.tsx's G and concluded the Tools glyphs were 16px, and @ux-lead corrected it by finding V2ConnectorTools.tsx:157's own local G. A same-size pin fails on either literal moving, which is the property that survives a reader who has the wrong mental model. Please keep that comment — it is the reason the test looks weaker than it is.

One caveat on the suite claim

The stated 113 suites / 1009 tests reproduces, but not on the first try: my first full run on a clean tree returned 1 failed / 1009, and the two runs after it were green. I cannot name the failing test — my first capture grepped only the totals, so the FAIL line is gone. That is my instrument gap, not a finding against this PR, and I am recording it rather than dropping it because an intermittent failure in the frontend tier is worth someone catching the name of. If a red appears here that nobody can explain, this is the first thing to suspect.

[lilyshen0722]

RE-GATE: PASS @ 84389ee4 — sprint-review. This supersedes my PASS @ 2b3c84bf, which is void: the head moved, correctly, because the defect was inside the artifact under gate.

Incremental diff, 2b3c84bf..84389ee4: 5 lines in one file — two assertions and three comment lines. Nothing rode along, which is the first thing a re-gate has to rule out.

+ expect(markSvg.getAttribute('height')).toMatch(/^\d+$/);
+ expect(modeSvg.getAttribute('height')).toMatch(/^\d+$/);

Every measurement below is taken at this head rather than carried over, because the changed file is the test itself — the instrument. Anchors all 1; the height controls count 2.

mutation	result
strip height from both G components (icons/glyphs.tsx and V2ConnectorTools.tsx:157)	1 failed / 60 — the gap is closed
drop size={14} at the mark's call site	1 failed / 60
V2ConnectorTools' local G 14 → 16	1 failed / 60
mark not rendered ({row.mark ? ( → {false ? ()	1 failed / 60 plus one sibling — the presence guard is intact

The first row is the one that matters: it is the mutation that was green before this change, re-run against the fix, and it now reds. The last three confirm the added assertions did not weaken anything that already worked.

BASE and RESTORED both 60/60 with git diff --quiet clean. npx tsc --noEmit exits 0 with zero output. Full suite 113 suites / 1009 tests green, twice.

Carry: behind 1, and that commit is #1979 (docs/assets/readme/connectors-2x.png and frontend/src/assets/landing/connectors.png) — disjoint from this PR's four files, git merge-tree --write-tree clean against current main. No rebase needed.

CI: 12 checks pass, two conditional main-guards skipping, Test & Coverage still running — which is the whole of the BLOCKED mergeStateStatus.

---

Finding 2 stands as written, and I would defend it against a later reviewer. The test pins the agreement rather than the value, so both glyphs moving to 16 together passes. That is deliberate and the comment says so. A 14 asserted in one file would have survived every misreading of this chain in the originating thread, including mine — I read icons/glyphs.tsx's G, concluded the Tools glyphs were 16px, and was corrected by @ux-lead finding V2ConnectorTools.tsx:157's own local G. A same-size pin fails on either literal moving, which is the property that survives a reader holding the wrong model.

On the intermittent suite failure I reported on the previous head: I am standing down from it. The combined tally is now 1 red in 9 runs — one of my three at 2b3c84bf, two green here, four green on the author's machine. It remains unnamed, and the single capture that could have named it was lost because my first grep took only the totals. At that rate it is not worth further time against this PR. If a red appears in this tier that nobody can account for, this is the first thing to suspect, and I will name it then.