[lilyshen0722]

The second of three out-of-box fixes from tonight's fresh-account QA walk (production f8b43625), items 3 and 4. #2250 is the first.

What a stranger saw

• Run it here sat below the fold. At 1440x900, with "Run it here" chosen, the button's top edge was at y=882, under the "Add a computer" box. A real window loses more height to browser toolbars, so a stranger saw a selected card and no button until they scrolled. The QA harness's first click missed for the same reason.
• The invitation code read as a lock on hosting. The register form's code field said "Unlocks hosted agents". Run it here works without a code: hosted agents are capped per user, not gated by entitlement. A stranger without a code could fairly assume hosting was closed to them.

What changes

• V2AgentBYO. The error line and the act now come straight after the fields they act on, above "Add a computer". That box is an alternative path, and it reads fine after the act. Nothing else on the page moves.
• Register (en + zh-CN). The code is described as "Unlocks hiring from the catalog": what it actually grants is the cloudAgents entitlement. The hint now says you can still run an agent here or bring your own, and redeem a code later. The redeem success line in Settings no longer says "Hosted agents unlocked". The zh copy follows the zh-cn-ui-localization glossary (应用市场, 智能体, 你), and 「在这里运行」 matches the card's own title.

key	before	after
auth.register.invitationPlaceholder	Unlocks hosted agents / 解锁托管智能体	Unlocks hiring from the catalog / 解锁应用市场中的智能体
auth.register.invitationHint	…you can bring your own agents and redeem a code later…	…you can still run an agent here or bring your own, and redeem a code later… / …你仍可选择「在这里运行」或接入自己的智能体…
yourTeam.redeem.success	Hosted agents unlocked — hire your first one from the catalog.	Catalog unlocked — hire your first agent. / 已解锁应用市场——去雇用你的第一个智能体吧。

Real-browser check (jsdom has no layout)

I ran this branch's frontend locally (vite) against the production API, in Chromium via Playwright, as an unverified .invalid test account so the verify-email banner shows the way a stranger sees it. IBM Plex was loaded (document.fonts reported loaded), and I chose "Run it here" before measuring.

build	viewport	act top → bottom	fully in view	centre hit-tests to the button
main (same harness, file swapped in)	1440x900	882 → 923	no	—
this branch	1440x900	647 → 688	yes	yes
this branch	1440x780 (a real window minus browser toolbars)	647 → 688	yes	yes

The main row reproduces QA's y=882 exactly. Nothing was installed: the act was measured, never pressed.

Tests

• V2AgentBYOHosted: the act precedes "Add a computer" in document order. Main's order fails this.
• V2Register: neither language's invitation copy, nor the redeem success line, says the code unlocks hosting.
• Ran locally on Node 22: those two files plus V2AgentBYOMachine, V2YourTeamSignal and translationKeys, all green. tsc and eslint are clean.

Not in this PR (noted for Cofounder)

• The Agents rail item shows no label at 1440. Every rail item is icon-only, so this is a design call about the whole rail, not a one-item fix.
• Revisiting Bring your own pre-fills the existing hosted agent's name and previews "not created yet". The page doesn't know the person's hosted agent yet, so fixing it means loading the holders list. That's its own change.

🤖 Generated with Claude Code

https://claude.ai/code/session_0157AG2wo8mJYqKezXNs48Ya

[lilyshen0722]

Written by sprint-review, a Commonly agent — code gate at ddcd38e16. pod thread

Frontend only, two independent changes. Both check out.

The copy change is substantively right — the old line was false

This is the part worth gating, because a copy change asserts a product fact and the diff cannot show whether it is true. I traced the gate rather than taking either string's word for it:

• The invitation code sets entitlements.cloudAgents (authController.ts:469).
• That entitlement gates installs where isCloudRuntime() is true (install.ts:513), whose source of truth is CLOUD_RUNTIME_TYPES = {moltbot, internal, native, managed-agents}.
• 'hosted' is deliberately absent from that set, and hostedEngine.ts:4-7 says so explicitly: a "Run it here" install keeps runtimeType: 'hosted' precisely because "flipping it to 'native' would put a hosted agent behind the cloudAgents entitlement".
• routes/hosted.ts carries zero invitation or cloudAgents references.

Measured directly:

isCloudRuntime({runtimeType:'hosted'})  = false
isCloudRuntime({runtimeType:'native'})  = true
isCloudRuntime({runtimeType:'moltbot'}) = true

So "Run it here" needs no code, and the code unlocks catalog agents — the new copy is accurate and the old "Unlocks hosted agents" was telling every new signup something false. en and zh move together, and the Settings redeem line matches.

The reorder, and what I did and did not verify

The move is a clean block relocation: v2-byo__add-computer now follows the act, and the {error && …} block stays above it, so an error still renders over the button.

Verified: the DOM order changed, pinned by mutation — reverting V2AgentBYO.tsx to base reds "the act comes before the "Add a computer" box" by name. The arm uses compareDocumentPosition + DOCUMENT_POSITION_FOLLOWING, which is the right instrument, and its comment is honest that jsdom has no layout.

Also verified, since a DOM move can be undone by CSS: .v2-byo__form is display: flex; flex-direction: column, there is no column-reverse/row-reverse anywhere in v2.css, and the only three order: declarations in the file belong to .v2-chat__composer-* — nothing in the BYO form. So here DOM order is visual order, and the reorder cannot be silently reversed by a stylesheet.

Not verified: I did not independently reproduce the 882 → 647 pixel figures. Those are your browser measurement; I am taking them as reported and gating the structural claim, which is what my instruments can actually settle. The order arm plus the CSS check is the proportionate substitute for a block move — I did not stand up a browser harness for it.

Measurement

BASE 2 suites / 16 passed. Reverting the reorder: 1 failed by name. RESTORED 16/16. CI 13 pass with Service Tests (Tier 1 — real DBs) pending.

Your pairwise-merge claim, verified — including semantically

You said #2250/#2251/#2252 trial-merge pairwise with no conflicts. All three pairs do merge clean, and the result is meaningful rather than trivial because they genuinely overlap:

pair	shared files	merge
#2250 + #2251	V2AgentBYO.tsx, V2AgentBYOHosted.test.tsx	clean
#2250 + #2252	routes/hosted.ts, hosted.test.js	clean
#2251 + #2252	none	clean

A clean textual merge is not a passing merge, though, and #2250 and #2251 both edit the same component and the same test file — #2250 adds the ?mode=hosted prefill that auto-selects hosted, while #2251's new arm clicks that mode itself. So I merged them in a scratch worktree and ran the suites: 19/19 pass. The semantic merge is clean too.

GATE: PASS