Open Alt-click comments directly

[max-sixty]

Alt-click already identifies both the target and the reader's intent, so this change opens the anchored comment composer immediately instead of first presenting the shared Comment/reaction bar.

Keyboard item selection with s remains a general target-selection gesture and still raises the shared response bar. The runtime now names those two transitions separately while retaining the same semantic anchor capture underneath them.

The browser coverage, public guidance, and release-notes example now reflect the direct path. The full test suite passes (746 tests), along with pre-commit and a light/dark, narrow/wide interaction sweep.

This was written by Codex on behalf of @max-sixty

[leaf-agent]

One stale claim left behind by the split. paintAnchors in skills/leaf/assets/runtime/anchors.js still accounts for the aim-and-composer coexistence with the old two-step: search for the paragraph beginning The ⌥ aim does not wear this paint — it says a press while the box is up "selects another target and raises its action bar". That is now what s does; the ⌥ press moves the draft. The PR updated both of its twins — aimedTarget's comment in aim.js and the docstring on test_the_aim_still_promises_while_a_composer_is_open — so this reads as a missed third copy rather than a deliberate keep. The paragraph's conclusion still holds; only the parenthetical mechanism is wrong (anchors.js#L744-L747).

    // why). An open composer doesn't stand the aim down — a press while the box is up
    // moves the draft onto another target — so the two can show at once, which is the
    // true state: where the draft stands, and where the next comment would land.

Happy to push that as a commit if you'd rather not round-trip it.

What else I checked

• openTargetComposer reproduces fab.onclick's three steps exactly (showFab(null, null, {returnFocus: "none"}) then openComposer(anchor, "", left, top)), so the direct path writes the same anchor the two-step wrote, and openComposer's draft-move branch is what carries typed text onto a re-aimed target.
• about can't drift on the new door: aimIsAvailable is () => !designIsOn(), so the aim branch is unreachable in design mode and openComposer's about default stays null.
• fabTargetAt/fabReturnTo are read only by reactions.js, which the aim no longer reaches, so leaving fabAnchor unset on this path strands nothing.
• The item outline survives the class change: lf-action-target is gone from the ⌥ route, and paintAnchors' pending branch puts lf-mark-el lf-pending on the same parts — which the rewritten flowchart test asserts.
• Reactions on a whole item stay reachable by s (rewritten test) and on visuals by plain click through activateVisual, so docs/index.html's "diagrams and images also expose response actions by click" holds.
• No other activateAimTarget or aim.respond reference is left anywhere in the tree, and no references/ or SKILL.md prose describes the old two-step.
• Every other Alt-click test in the suite asserts the promise or the design-mode path rather than the bar, so the update looks complete; ci is green on this head.

[max-sixty]

Updated the remaining paintAnchors explanation in ce4e31c so it describes the direct Alt-click behavior: the open draft moves to the newly aimed target, with no intermediate action bar.

This was written by Codex on behalf of @max-sixty