#19 · stacks/uplink

Part of #4.

The engine name is spread across five places in one file: two head consts, the steps array, the install array, the faqs array, and three sections of markup. Most of those strings only name Claude and can be reworded in place. Three state facts that are true of Claude and of no other engine: the claude setup-token flow and the Keychain, the plan that absorbs the cost, and the per-repository instruction file. Those cannot be made engine-neutral by wording, so they have to state both engines. The list below is the verified set with anchors, so the engine work does not have to re-derive it from a grep.

What is there today

The head takes both of its strings from two consts: resources/views/index.stx#L16 is the <title> text and #L17 the description. They render four times, at #L93, #L94, #L98 and #L99, so those two edits move the tab title, the meta description, og:title and og:description together.
The hero names Claude twice: the h1 at resources/views/index.stx#L192 and the subhead at #L195, which repeats #L17 word for word.
How it works names Claude in its h2 at resources/views/index.stx#L244 and in the Run step body at #L35, rendered by the loop at #L255.
The bento cell at resources/views/index.stx#L288 names CLAUDE.md as the per-repository instruction file. It is a filename rather than the engine's name, which is why it is easy to skim past, but it is user-visible copy and a second engine reads a different file.
The download section names Claude in its subhead at resources/views/index.stx#L320, in install step 2 at #L54 (rendered at #L333), and in the screenshot alt text at #L347.
Three FAQ answers name Claude: resources/views/index.stx#L70 (FAQ 3, the API key), #L74 (FAQ 4, what it can do) and #L78 (FAQ 5, the cost). All three render through at #L366.
#L70 is the only answer whose facts are engine-specific rather than engine-named. It states claude setup-token and the Keychain. #L78 bills against "your Claude plan". Both are wrong for a second engine's auth and billing, not merely worded for one.
Two things need no change. resources/views/index.stx#L101, the og:image:alt, describes the hero photo and never names the engine. The two exchanges at #L19-L30 are real replies, which the header comment at #L9-L11 commits the page to, and neither names the engine. resources/views/404.stx has no Claude string at all.
Copy in the three arrays has no room for structure. #L366 renders one escaped string into one <p>, and #L255 and #L333 do the same for . An answer that sets out two engines' auth flows as separate paragraphs or list items needs that markup changed.
The page cannot branch on the reader's engine. Its only data import is resources/data/release.json at resources/views/index.stx#L47, and it is one public view served to every visitor, so a forked answer has to name both engines in the same paragraph.

Proposal

Put the breadth in the mechanism copy. Rewrite resources/views/index.stx#L35, #L244 and #L320 so the engine is named as one of two, for example "Claude Code or Codex" in the Run step and the download subhead, and an h2 that does not name a single engine's session.
Leave a named engine in the two strongest strings. #L192 and #L16 keep "Claude". The <title> at #L16 is 55 characters today, and listing both engines pushes it past the length search results show, which is a second reason to leave it alone.
Fork the API key answer at #L70. Keep the opening "No", then give each engine its own path: the Claude Code CLI on a Claude plan through a token from claude setup-token, and the other engine's own sign-in, both held in the Keychain. Check the wording against the app's auth code rather than writing it from the old answer.
Fork the cost answer at #L78 the same way, so it reads as nothing on top of the plan you already have for the engine you chose, and keep the sentence about the dashboard showing what each run would have cost at API rates, in cents.
Change #L288 to name both instruction files, or to say "that repository's agent instructions, hooks and settings" with the filenames after it.
Reword install step 2 at #L54 so it says signing in to the engine you chose. Reword #L17 and the hero subhead at #L195 in the same pass, since they are one sentence written twice.
Leave #L347 until the screenshot itself changes, then rewrite it to match the new image.

Requirements

The alt text follows the image, not the copy. #L347 describes public/images/menubar-setup.png, whose setup step says to sign in to Claude. Editing the alt before the screenshot is retaken makes it describe something the image does not show.
The two exchanges stay byte for byte. #L19-L30 are real replies from real runs and the header comment at #L9-L11 is a promise about them. Nothing here touches them.
The hero keeps one engine named. The goal is copy that survives a second engine, not the page's strongest line flattened into "your agent".
A forked answer that needs two paragraphs needs markup. #L366 is one <p> around one escaped string. Either hold each forked answer to a single paragraph, or change the loop at #L360-L366 so an answer can carry structure.
Editing #L16 or #L17 moves four rendered tags. Re-read #L93, #L94, #L98 and #L99 afterwards, and check a social card preview, not only the page.
No em-dash and no en-dash. resources/views/index.stx has none today and AGENTS.md#L441 forbids them in user-visible strings. Copy edits are exactly where that rule gets broken.
This is copy only. No new views, no route changes, no engine selection logic. The engine work is tracked separately.

Acceptance

grep -n Claude resources/views/index.stx returns only lines that are deliberately Claude-specific: the title at #L16, the h1 at #L192, and the Claude half of the two forked FAQ answers. Every other hit from today's thirteen either names both engines or is gone.
FAQ 3 and FAQ 5 each state the auth path and the billing for both engines, and a reader on either one can follow them without guessing.
The tab title, meta description, og:title and og:description all render the edited consts, verified in the built page and in a social card preview.
#L19-L30 and #L101 are unchanged, and #L347 still matches the image it describes.
grep -n '[—–]' resources/views/index.stx returns nothing.
./buddy lint passes and the diff touches only resources/views/index.stx.