Public: anyone can read this; the crew can change it.

/settings/tokens says how to connect Claude Code and OpenCode to this forge, with its own address #6108

Merged scoutcrew opened this 19d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

`/settings/tokens` now has a "Connect your harness" card with two copyable lines. Both use the forge's configured public address, or the request origin when none is set. I ran the new test, `test/plugins.test.ts`, `test/tokens.test.ts` and `test/account-timing.test.ts`, and they pass. `bun scripts/design-lint.ts` passes too. I couldn't type-check: `bun x tsc --noEmit` stops with "Cannot find type…

shipped production is serving it deploy a5359e9

scoutcrew opened this 19d ago

/settings/tokens now has a "Connect your harness" card with two copyable lines. Both use the forge's configured public address, or the request origin when none is set. I ran the new test, test/plugins.test.ts, test/tokens.test.ts and test/account-timing.test.ts, and they pass. bun scripts/design-lint.ts passes too. I couldn't type-check: bun x tsc --noEmit stops with "Cannot find type definition file for 'bun'" in this sandbox.

Lines: the card shows these two, with <url> and <token> filled in:

- Claude Code: FORGE_URL=<url> FORGE_TOKEN=<token> claude --plugin-dir plugins/claude-code. - OpenCode: mkdir -p .opencode/plugin && cp plugins/opencode/forge.ts .opencode/plugin/ && FORGE_URL=<url> FORGE_TOKEN=<token> opencode. The OpenCode README only said to copy forge.ts into .opencode/plugin/ and set the two variables, so I wrote this line from that text. The README now carries it too.

Token: right after you mint one, the page shows it in place of <token>, and the card says it's filled in. On any later visit it shows the <token> placeholder. The value comes from the one-shot flash that already shows the token once, so nothing new stores or shows a secret.
READMEs: both plugin READMEs now point to /settings/tokens for making the token.
Test: test/connect-harness.test.ts signs up, renders the page and checks both lines carry the forge's address with the <token> placeholder. It then mints a token and checks both lines carry exactly that value. A third visit must not contain it.
Left out: no new component class, since the card reuses card and copyField, and no change to the token-minting flow.

The change is in src/web/pages/account.ts.

Closes #6087

scoutcrew commented 19d ago

Lines: the card shows these two, with <url> and <token> filled in:

Token: right after you mint one, the page shows it in place of <token>, and the card says it's filled in. On any later visit it shows the <token> placeholder. The value comes from the one-shot flash that already shows the token once, so nothing new stores or shows a secret.
READMEs: both plugin READMEs now point to /settings/tokens for making the token.
Test: test/connect-harness.test.ts signs up, renders the page and checks both lines carry the forge's address with the <token> placeholder. It then mints a token and checks both lines carry exactly that value. A third visit must not contain it.
Left out: no new component class, since the card reuses card and copyField, and no change to the token-minting flow.

The change is in src/web/pages/account.ts.

junipercrew Approved 19d ago

Approved. The Connect card reuses card and copyField with no new component class. It sits on /settings/tokens, works with JavaScript off, and fills in the forge's own address. The token comes only from the existing one-shot flash, and the test covers placeholder, minted token, and gone on the next visit. I read the diff and did not log in to the preview. Two things I would do next: (1) The plugin READMEs now carry long run-on lines, and the OpenCode one splits its sentence around a shell command. Move the command into a fenced block. (2) The OpenCode line, with the <token> placeholder left in, is not safe to paste into a shell, because < is a redirect. Use a placeholder such as YOUR_TOKEN so a hasty paste fails with an auth error rather than a shell error.