An admin signed in at the terminal is asked once to work day to day as an everyday account, as the home card asks #8086

I merged main into this branch again. The only conflict was one line in test/egress-admin.test.ts, and the merge is pushed.

Why it conflicted: this branch and #8039 on main both changed the egress-admin test to wait for the confirm that pressing x now opens before a grant is revoked. This branch waits for the dialog's title, Stop ada/arm reaching …?. main waits for the Revoke button label. Both strings are in the same confirm in src/tui/screens/egress.ts:98-100, so the two sides meant the same thing.

What I kept: this branch's line, because the title names the repo, so the test checks it is confirming the right grant. The rest of the test is unchanged. It still checks the grant survives until y and is gone after.

Checks:

• bun scripts/gate.ts and bun x tsc --noEmit both pass.
• test/egress-admin.test.ts, test/tui-egress.test.ts and test/tui-deploys-egress.test.ts pass: 11 tests, 0 failures.
• I did not run the other 219 test files scripts/fast.ts named for this diff (about 18 minutes). The forge's check on this push covers them.

🤖 Generated with Claude Code

Continues #8086

I merged main into this branch again. The only conflict was one line in test/egress-admin.test.ts, and the merge is pushed.

Why it conflicted: this branch and #8039 on main both changed the egress-admin test to wait for the confirm that pressing x now opens before a grant is revoked. This branch waits for the dialog's title, Stop ada/arm reaching …?. main waits for the Revoke button label. Both strings are in the same confirm in src/tui/screens/egress.ts:98-100, so the two sides meant the same thing.

What I kept: this branch's line, because the title names the repo, so the test checks it is confirming the right grant. The rest of the test is unchanged. It still checks the grant survives until y and is gone after.

Checks:

• bun scripts/gate.ts and bun x tsc --noEmit both pass.
• test/egress-admin.test.ts, test/tui-egress.test.ts and test/tui-deploys-egress.test.ts pass: 11 tests, 0 failures.
• I did not run the other 219 test files scripts/fast.ts named for this diff (about 18 minutes). The forge's check on this push covers them.

🤖 Generated with Claude Code

The terminal's dashboard (src/tui/screens/dashboard.ts) now asks a forge admin about an everyday account, the same question the web home asks. When askForEveryday(db, user) is true, one muted line sits at the top of the screen: EVERYDAY_WHY, then "E makes it on the web · K keeps using admin".

• E opens /settings with the existing openOnWeb helper, where the web's form for the everyday account lives.
• K calls keepAdmin(db, user). The line goes for good, and the web stops asking too.
• Once an everyday account is linked (everydayOf), the line says "Day to day you are <name>; this is the admin account." instead.
• Everyone else (non-admins, agents, organisations, an everyday account itself) gets no row, so their layout doesn't move.

Keys differ from the issue. The issue asks for m and k. On this screen k already moves the cursor up and m already mutes, so an admin moving up a list would make a permanent choice by accident. I used the capitals E and K instead; capitals already mark deliberate actions here (S, Z). The test checks that k still makes no choice.

Why the last pull (#8052) went red: it was not this feature. The failure was in tui system telemetry grant > anyone the tool refuses… (test/tui-system.test.ts). That test reads a refusal toast after a settle, and a toast lasts 4 s by default, so on a loaded check run it had expired before the test read it. The test was wrong: it now passes toastMs: 10 * 60_000, the option the app has for tests that read a toast after a settle. Nothing in the app changed for that fix.

Also in this pull:

• main is merged in. The one conflict was test/egress-admin.test.ts, where main had made the same fix this branch carried, so it now matches main exactly.
• While I worked, the forge's own committer swept work in progress from this clone into commits 49ccf2f3 and ced74b74, with a message that names #8086. Their content is this pull's, and 9b1153f3 puts test/egress-admin.test.ts back to main's version.

Tests: test/tui-everyday.test.ts covers an admin who hasn't chosen seeing the line, K setting keptAdmin and removing the line (a fresh session isn't asked again), a linked admin seeing their everyday account's name, and a non-admin or agent never seeing it.

Checks run: bun scripts/gate.ts and bun x tsc --noEmit are clean. These pass: test/tui-everyday.test.ts, test/tui-system.test.ts (run 5 times), test/egress-admin.test.ts and the dashboard and home TUI suites. I left the full suite to the forge's check. Nothing under src/web/ changed, so design-lint doesn't apply.

To try it: sign in at the terminal as a forge admin who hasn't chosen yet. The line is the first row of the dashboard. Press K and it's gone, here and on the web home.

🤖 Generated with Claude Code

Closes #8046

A forge admin signed in at the terminal who hasn't yet chosen how to work day to day now gets the web home card's question once, as one muted line at the head of the dashboard. E opens Settings on the web to make the everyday account. K keeps admin and records the choice through the same keepAdmin the web reads, so neither door asks again. Once an everyday account is linked, the line names it instead: Day to day you are <name>; this is the admin account. Anyone who is not an admin, and any agent, sees no line and neither key, and k still moves the cursor.

This push adds the docs @juniper asked for:

• docs/TOUR.md: a paragraph after the Resilience dialog one, beside the other terminal paragraphs. It says what the muted line shows, what E and K do, and what the line says once an account is linked. It also says why E goes to the web: the everyday account is made with a passkey, which a terminal cannot hold, so the terminal never makes the account itself.
• README.md: a matching bullet in the list of terminal keys, after "Stop running as an app at the terminal".

To look at: the dashboard code is src/tui/screens/dashboard.ts (everydayHead, keepAdminHere, and the E/K keys near line 1234). The tests are in test/tui-everyday.test.ts. They cover the ask, K recording the choice so the web stops asking, the linked account's name, and that non-admins and agents see nothing.

Checks: bun scripts/gate.ts passes. test/tui-everyday.test.ts and the four README tests (readme-cap, readme-front-door, readme-cache, readme-home-cut) pass. This push changes only docs, so I didn't rerun the type check; it passed on the last code push.

To try it: sign in at the terminal as a forge admin with no everyday account and no choice made, and read the line at the top of the dashboard. Press K and it changes, and the web home stops asking too.

🤖 Generated with Claude Code

The terminal's dashboard (src/tui/screens/dashboard.ts) now asks a forge admin about an everyday account, the same question the web home asks. When askForEveryday(db, user) is true, one muted line sits at the top of the screen: EVERYDAY_WHY, then "E makes it on the web · K keeps using admin".

• E opens /settings with the existing openOnWeb helper. The everyday account is made with a passkey, which a terminal cannot hold, so the terminal never makes it itself.
• K calls keepAdmin(db, user). The line goes for good, and the web stops asking too.
• Once an everyday account is linked (everydayOf), the line says "Day to day you are <name>; this is the admin account." instead.
• Everyone else (non-admins, agents, organisations, an everyday account itself) gets no row, so their layout doesn't move.

Keys differ from the issue. The issue asks for m and k. On this screen k already moves the cursor up and m already mutes, so an admin moving up a list would make a permanent choice by accident. I used the capitals E and K instead; capitals already mark deliberate actions here (S, Z). The test checks that k still makes no choice.

Why the last pull (#8052) went red: it was not this feature. The failure was in tui system telemetry grant > anyone the tool refuses… (test/tui-system.test.ts). That test reads a refusal toast after a settle, and a toast lasts 4 s by default, so on a loaded check run it had expired before the test read it. The test was wrong: it now passes toastMs: 10 * 60_000, the option the app has for tests that read a toast after a settle. Nothing in the app changed for that fix.

Also in this pull:

• README.md and docs/TOUR.md describe the line and the two keys.
• main is merged in, and test/egress-admin.test.ts is now exactly main's.
• Two commits, 49ccf2f3 and ced74b74, were made from this clone by the forge's committer during an earlier run. One of their messages names #8086. Their content is this pull's.

Tests: test/tui-everyday.test.ts covers an admin who hasn't chosen seeing the line, K setting keptAdmin and removing the line (a fresh session isn't asked again), a linked admin seeing their everyday account's name, and a non-admin or agent never seeing it.

Checks run: bun scripts/gate.ts and bun x tsc --noEmit are clean. These pass: test/tui-everyday.test.ts, test/tui-system.test.ts, test/egress-admin.test.ts and the dashboard and home TUI suites (35 tests). I left the full suite to the forge's check. Nothing under src/web/ changed, so design-lint doesn't apply.

To try it: sign in at the terminal as a forge admin who hasn't chosen yet. The line is the first row of the dashboard. Press K and it's gone, here and on the web home.

🤖 Generated with Claude Code

Closes #8046

Hi — I left the branch as it was; there was nothing new to push. Pull #8086's check is still running on the current head, 53d5a857, so I can't say yet whether it will pass. main has moved one commit since (#8087, the About card's visibility key), but that touches different files and merges with no conflict. Merging it now would only restart that check.

The terminal's dashboard (src/tui/screens/dashboard.ts) now asks a forge admin about an everyday account, the same question the web home asks. When askForEveryday(db, user) is true, one muted line sits at the top of the screen: EVERYDAY_WHY, then "E makes it on the web · K keeps using admin".

• E opens /settings with the existing openOnWeb helper. The everyday account is made with a passkey, which a terminal cannot hold, so the terminal never makes it itself.
• K calls keepAdmin(db, user). The line goes for good, and the web stops asking too.
• Once an everyday account is linked (everydayOf), the line says "Day to day you are <name>; this is the admin account." instead.
• Everyone else (non-admins, agents, organisations, an everyday account itself) gets no row, so their layout doesn't move.

Keys differ from the issue. The issue asks for m and k. On this screen k already moves the cursor up and m already mutes, so an admin moving up a list would make a permanent choice by accident. I used the capitals E and K instead; capitals already mark deliberate actions here (S, Z). The test checks that k still makes no choice.

Why the last pull (#8052) went red: it was not this feature. The failure was in tui system telemetry grant > anyone the tool refuses… (test/tui-system.test.ts). That test reads a refusal toast after a settle, and a toast lasts 4 s by default, so on a loaded check run it had expired before the test read it. The test was wrong: it now passes toastMs: 10 * 60_000, the option the app has for tests that read a toast after a settle. Nothing in the app changed for that fix.

Also in this pull:

• README.md and docs/TOUR.md describe the line and the two keys.
• main is merged in up to #8089, and test/egress-admin.test.ts is exactly main's.
• Two commits, 49ccf2f3 and ced74b74, were made from this clone by the forge's committer during an earlier run. One of their messages names #8086. Their content is this pull's.

Tests: test/tui-everyday.test.ts covers an admin who hasn't chosen seeing the line, K setting keptAdmin and removing the line (a fresh session isn't asked again), a linked admin seeing their everyday account's name, and a non-admin or agent never seeing it.

Checks run: bun scripts/gate.ts and bun x tsc --noEmit are clean. These pass: test/tui-everyday.test.ts, test/tui-system.test.ts, test/egress-admin.test.ts and the dashboard and home TUI suites (35 tests). I left the full suite to the forge's check. Nothing under src/web/ changed, so design-lint doesn't apply.

To try it: sign in at the terminal as a forge admin who hasn't chosen yet. The line is the first row of the dashboard. Press K and it's gone, here and on the web home.

🤖 Generated with Claude Code

Closes #8046

The terminal's dashboard (src/tui/screens/dashboard.ts) now asks a forge admin about an everyday account, the same question the web home asks. When askForEveryday(db, user) is true, one muted line sits at the top of the screen: EVERYDAY_WHY, then "E makes it on the web · K keeps using admin".

• E opens /settings with the existing openOnWeb helper. The everyday account is made with a passkey, which a terminal cannot hold, so the terminal never makes it itself.
• K calls keepAdmin(db, user). The line goes for good, and the web stops asking too.
• Once an everyday account is linked (everydayOf), the line says "Day to day you are <name>; this is the admin account." instead.
• Everyone else (non-admins, agents, organisations, an everyday account itself) gets no row, so their layout doesn't move.

Keys differ from the issue. The issue asks for m and k. On this screen k already moves the cursor up and m already mutes, so an admin moving up a list would make a permanent choice by accident. I used the capitals E and K instead; capitals already mark deliberate actions here (S, Z). The test checks that k still makes no choice.

Why earlier checks were red: neither failure came from this feature. Each was a test that was wrong, and each test is fixed here; no app code changed for either.

• #8052: tui system telemetry grant > anyone the tool refuses… (test/tui-system.test.ts) reads a refusal toast after a settle. A toast lasts 4 s by default, so on a loaded run it had expired before the test read it. The test now passes toastMs: 10 * 60_000, the option the app has for this.
• Previous push of #8086: tui-pull-hold failed with Cannot use a closed database, thrown from an issue screen's frame. test/tui-issue-flow-first.test.ts never stopped the terminals it opened, so one kept drawing after its afterAll closed the database, and bun blamed the next file in the shard. Running the two files together in one process fails every time, with main's dashboard as well as this one. The test now stops every terminal it opened before closing the database, and the six files of that shard run together pass 3 times out of 3.

Also in this pull: README.md and docs/TOUR.md describe the line and the two keys. main is merged in. The forge's committer made two commits in this clone during an earlier run, 49ccf2f3 and ced74b74, and one of their messages names #8086. Their content is this pull's.

Tests: test/tui-everyday.test.ts covers an admin who hasn't chosen seeing the line, K setting keptAdmin and removing the line (a fresh session isn't asked again), a linked admin seeing their everyday account's name, and a non-admin or agent never seeing it.

Checks run: bun scripts/gate.ts and bun x tsc --noEmit are clean. 38 tests across 9 files pass: everyday, system, egress-admin, issue-flow-first, pull-hold, and the dashboard and home TUI suites. I left the full suite to the forge's check. Nothing under src/web/ changed, so design-lint doesn't apply.

To try it: sign in at the terminal as a forge admin who hasn't chosen yet. The line is the first row of the dashboard. Press K and it's gone, here and on the web home.

🤖 Generated with Claude Code

Closes #8046