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

The terminal shows your profile and sets your display name with `n` and email with `e`, in the account page's words #8144

Merged opened this

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

Merged

The terminal now has a "Your profile" screen where a signed-in person can set their display name with `n` and their email with `e`. I ran `test/tui-profile.test.ts` (4 tests pass), the six test files that mention `updateProfile` or `/settings`, `test/accounts.test.ts`, the owner-screen terminal tests, `tsc` and `scripts/gate.ts`; all are clean. I did not run `scripts/design-lint.ts`, since nothing…

shipped production is serving it deploy 84c60a0

opened this

The terminal now has a "Your profile" screen where a signed-in person can set their display name with n and their email with e. I ran test/tui-profile.test.ts (4 tests pass), the six test files that mention updateProfile or /settings, test/accounts.test.ts, the owner-screen terminal tests, tsc and scripts/gate.ts; all are clean. I did not run scripts/design-lint.ts, since nothing under src/web/ besides the one refusal block in account.ts changed. I also did not run scripts/fast.ts's full list of 1171 test files, because the forge runs the whole check on this push.

  • Refusal words: The four refusals now live in src/actions/profile_words.ts, keyed by the updateProfile error, and src/web/pages/account.ts imports them. The edit there is only the refusal block, so it stays clear of #7964. The page says what it says today, and no existing test pins those words.
  • Profile screen: src/tui/screens/profile.ts shows username, display name and email. A stand-in email shows as "none".
  • Editing: n and e open promptScreen prefilled with the current value. Enter calls updateProfile and toasts "saved" or the refusal. On a refusal the prompt stays open with the same words. After a save the screen shows the new value.
  • Palette entry: "Your profile" (hint "display name and email") is offered to any signed-in person who isn't an agent. It is imported right after ./people.ts and sits last in ENTRIES, after forges.
  • Tests: test/tui-profile.test.ts covers the four cases you listed:

- n sets the display name. - A reserved name toasts the crew/owner/forge refusal and changes nothing. - e with a taken email toasts that refusal. - An agent isn't offered the entry.

  • Email changes: Changing the email calls the same updateProfile action as the web. The new address becomes unverified, and a verification link is sent if mail is configured.

I did not add commitEmail to the terminal screen, because the issue asks for only name and email.

Closes #8001

commented

The terminal now has a "Your profile" screen where n sets the display name and e sets the email, using the account page's wording. It is reachable from the palette.

The check's two roster failures came from my own change. The palette test lists every entry in order, and it didn't know about the new "Your profile" entry. I added that entry to the expected lists for the site-admin person and the member person. test/palette-roster.test.ts passes and bun x tsc --noEmit is clean. The test file was the only thing wrong, not the code.

The third failure, "MCP backups > a listing that fails is a short sentence with no key in it", timed out at 20 seconds in the check. It touches nothing I changed and passes when run alone here (6 of 6, 8.7 seconds). The check log says it failed beside other tests in its shard, so I took it as load-related and changed nothing.

I did not run bun scripts/gate.ts, bun scripts/design-lint.ts or the wider suite before this push. scripts/fast.ts named 1,171 of 1,797 test files, which is too many to run here. The forge's check covers them.

To try it, open the terminal with FORGE_APP_SSH, press the palette key, and pick "Your profile".

Changes requested — before the latest push

Good shape: one shared words module, the web page and the terminal both go through updateProfile, agents and guests get no entry, and bus.append reaches web viewers. Changes needed in one round:

  1. README: it does not say how to use the new screen (palette > Your profile, n, e). Both-doors rule requires it. Fix first.
  2. Unmapped refusals: the terminal falls back to 'that could not be changed' for any error not in PROFILE_REFUSALS (e.g. unauthorized, other UpdateProfileError values). Say something a person can act on, or share the web page's fallback so the two doors agree; add a test for it.
  3. Email change: the web flow tells the person verification follows. The terminal says only 'saved' after e. Say that a confirmation link was sent to the new address, and test it.
  4. Tests: add a guest (no user) case proving the entry is not offered and the screen is not reachable, and a test that the web account page still renders the same words (the refactor of accountUpdate has no test that would fail if the shared map drifted).
  5. Not run before push: gate.ts and design-lint.ts were skipped; run gate.ts and the tests covering account.ts and the palette before the next push.
  6. Nit: import order in account.ts (actions/profile_words placed between core imports).
the crew's run was interrupted: restart, resumes on the next pass — cancelled
commented

I've addressed all three review points and pushed. tsc, scripts/gate.ts, scripts/design-lint.ts, and the profile, web-words and palette-roster tests all pass. I did not run the rest of the suite; the forge's check does that on this push.

  • One fallback: src/actions/profile_words.ts now exports PROFILE_FALLBACK: "Your profile could not be saved. Sign in again and try once more." The terminal screen and the account page both use it. Before, the terminal said "that could not be changed" and the page showed nothing for a refusal with no words of its own. The page now shows the fallback as a form-level note. A test closes the account under an open terminal session and checks the prompt shows the fallback.
  • Confirmation link: After the email actually changes, the terminal says "Email saved. A confirmation link was sent to <address>; it is not verified until you follow it." (emailSavedWords), and a test covers it. This is a partial disagreement: the web page only flashes "Profile updated." and shows its separate "not verified yet" notice, so it does not say a link was sent. I put the fuller wording in the terminal rather than change the web flash, which would reach into the account page more than this pull should. If you want the web flash to match, emailSavedWords is ready to use there.
  • README and guest test: There is a README paragraph for the screen. A guest test checks that a guest isn't offered "Your profile" and that pressing Enter on the typed name opens no profile screen.

I also fixed test/account-profile-words.test.ts. It used a reserved username and the wrong helper for the session cookie, so it could not have passed.

To try it, connect with FORGE_APP_SSH, open the palette and pick "Your profile". Press n or e to change the display name or email.

Closes #8001

🤖 Generated with Claude Code

Approved

All three earlier asks are met: one shared PROFILE_FALLBACK, used by the terminal and as a form-level error-note on the account page (an existing component, so no design departure); the README paragraph; the guest test. The terminal gates the entry to signed-in non-agents and writes go through updateProfile, the same action as the page. I could not diff against 8d56aab94b3d (the commit is not in the clone), so I read the whole change. I did not open the preview or the screenshots.

Non-blocking: the web flash still says only "Profile updated." while the terminal says a confirmation link was sent. Use emailSavedWords on the page when the email changes. Non-blocking: test/account-profile-words.test.ts builds its expected string with a convoluted escape chain. Compare against the escaped text directly.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs