Sandbox admin panel: confirm updates land from main, manage access and keys, and let a tester invite a co-user

mik-tf commented

2026-06-05 16:33:14 +00:00

Owner

Goal: give the admin panel (and the tester cockpit, for the invite part) three things the sandbox still lacks. See that updates really reached each tester machine and came from main, manage access and keys for admins and testers, and let a tester bring another person into their own account.

1. Updates land from main, and we can see it in the admin panel

For each tester machine, show the build it is running and whether that build came from main, so an admin can confirm at a glance that an update actually applied.
Make updating a machine reliable and checkable: trigger the update, watch it progress, and confirm the new build is live, instead of guessing.
This builds on #244 (getting components to publish from main). The new part is the admin-panel visibility and the confidence that the update really took.

2. Access and key management in the admin panel

Admin support keys: today the keys we inject into tester machines for support are a fixed list set at provisioning. Let an admin view, add, and remove these from the panel.
Tester access: manage which Forge accounts are allowed into a given tester machine (the access list) from the panel.
Optional per-tester shell key: keep the current default of no SSH key for a tester, since a normal tester only uses the browser. Add a per-tester toggle, off by default, that lets an admin turn on SSH access for a technical tester and manage that tester's key. With the toggle off, nothing changes from today. This keeps the simplification in #247 as the default and only adds an opt-in.
Assistant provider keys: in the panel an admin can store a default key for any supported assistant provider (Groq, OpenRouter, SambaNova, Kimi). These are the keys a new tester's assistant can start with so it works the moment they log in. Keys stay in the secret store and are never shown back, only reported as set or not set.
Choose what to seed per tester: when adding a tester, the admin chooses whether to put the configured assistant keys onto that machine. The default is on, with every provider that has a configured key selected. The admin can narrow it to a subset (for example only Kimi) or turn it off entirely, in which case the tester starts with no assistant key and can add their own on the cockpit settings page. A tester can always replace a provided key with their own later.
Email service and sender: let an admin set the email service (Resend) API key and the from address and name from the panel instead of only as a server side secret set by hand, so a new node needs no manual step before it can send.
Customize the welcome email: let an admin edit the welcome email subject, opening paragraph, and sign-off from the panel. The login link and the sign in instructions (including the one time password for a new account) are always added by the system, so a customized email can never drop the parts a tester needs to get in. A blank field uses the built in default text.
Send a test welcome: an admin can send a test copy of the welcome email to an address they choose, using the current sender and customized text with sample details, to check it before any tester receives one.
Turn the welcome email on or off: a per-tester switch to send or skip the welcome email when that machine is ready, on by default, plus an instance wide on or off for the whole admin machine so email can be paused while keeping the key configured.

3. A tester can invite another person into their own account

From the cockpit, a tester can invite another person to share the same account and context, so two people work in one cockpit. Example: Ruy invites Flo, Flo signs in with her own Forge account and lands in Ruy's cockpit with the same access.
This is different from an admin adding a separate tester (#247) and from opening one shared app link to an anonymous viewer (#251). Here the invited person becomes a full co-user of the inviter's account.
If the invited person does not have a Forge account yet, set one up as part of the flow.

Related: #239 (sandbox readiness meta), #244, #247, #251.

Signed-by: mik-tf mik-tf@noreply.invalid

Goal: give the admin panel (and the tester cockpit, for the invite part) three things the sandbox still lacks. See that updates really reached each tester machine and came from main, manage access and keys for admins and testers, and let a tester bring another person into their own account. **1. Updates land from main, and we can see it in the admin panel** - For each tester machine, show the build it is running and whether that build came from main, so an admin can confirm at a glance that an update actually applied. - Make updating a machine reliable and checkable: trigger the update, watch it progress, and confirm the new build is live, instead of guessing. - This builds on https://forge.ourworld.tf/lhumina_code/home/issues/244 (getting components to publish from main). The new part is the admin-panel visibility and the confidence that the update really took. **2. Access and key management in the admin panel** - Admin support keys: today the keys we inject into tester machines for support are a fixed list set at provisioning. Let an admin view, add, and remove these from the panel. - Tester access: manage which Forge accounts are allowed into a given tester machine (the access list) from the panel. - Optional per-tester shell key: keep the current default of no SSH key for a tester, since a normal tester only uses the browser. Add a per-tester toggle, off by default, that lets an admin turn on SSH access for a technical tester and manage that tester's key. With the toggle off, nothing changes from today. This keeps the simplification in https://forge.ourworld.tf/lhumina_code/home/issues/247 as the default and only adds an opt-in. - Assistant provider keys: in the panel an admin can store a default key for any supported assistant provider (Groq, OpenRouter, SambaNova, Kimi). These are the keys a new tester's assistant can start with so it works the moment they log in. Keys stay in the secret store and are never shown back, only reported as set or not set. - Choose what to seed per tester: when adding a tester, the admin chooses whether to put the configured assistant keys onto that machine. The default is on, with every provider that has a configured key selected. The admin can narrow it to a subset (for example only Kimi) or turn it off entirely, in which case the tester starts with no assistant key and can add their own on the cockpit settings page. A tester can always replace a provided key with their own later. - Email service and sender: let an admin set the email service (Resend) API key and the from address and name from the panel instead of only as a server side secret set by hand, so a new node needs no manual step before it can send. - Customize the welcome email: let an admin edit the welcome email subject, opening paragraph, and sign-off from the panel. The login link and the sign in instructions (including the one time password for a new account) are always added by the system, so a customized email can never drop the parts a tester needs to get in. A blank field uses the built in default text. - Send a test welcome: an admin can send a test copy of the welcome email to an address they choose, using the current sender and customized text with sample details, to check it before any tester receives one. - Turn the welcome email on or off: a per-tester switch to send or skip the welcome email when that machine is ready, on by default, plus an instance wide on or off for the whole admin machine so email can be paused while keeping the key configured. **3. A tester can invite another person into their own account** - From the cockpit, a tester can invite another person to share the same account and context, so two people work in one cockpit. Example: Ruy invites Flo, Flo signs in with her own Forge account and lands in Ruy's cockpit with the same access. - This is different from an admin adding a separate tester (https://forge.ourworld.tf/lhumina_code/home/issues/247) and from opening one shared app link to an anonymous viewer (https://forge.ourworld.tf/lhumina_code/home/issues/251). Here the invited person becomes a full co-user of the inviter's account. - If the invited person does not have a Forge account yet, set one up as part of the flow. Related: https://forge.ourworld.tf/lhumina_code/home/issues/239 (sandbox readiness meta), https://forge.ourworld.tf/lhumina_code/home/issues/244, https://forge.ourworld.tf/lhumina_code/home/issues/247, https://forge.ourworld.tf/lhumina_code/home/issues/251. Signed-by: mik-tf <mik-tf@noreply.invalid>

mik-tf referenced this issue

2026-06-05 16:58:49 +00:00

[META] Hero OS sandbox demo, functional readiness: onboarding pipeline + per-app verification #239

mik-tf commented

2026-06-06 18:21:13 +00:00

Author

Owner

Plan for the email and key setup in part 2. We will add one Service setup panel to the deployer admin dashboard so an operator can set the service keys from the browser instead of by hand on the server. It covers the Resend email key with the from address and from name (the welcome-email sender bullet above), and we are extending it in the same panel to also hold the default OpenRouter and Kimi keys a new tester should start with, which keeps with the goal of having the whole sandbox configurable from one place. Every key field is write-only, so the panel shows only whether a key is set and never the value, and saving stores the values in the hero_proc secret store. The welcome-email sender will read its config live when it sends, so a change from the panel takes effect on the next email without a server restart. When a tester is provisioned, the install step seeds that tester with the default OpenRouter and Kimi keys so the assistant works as soon as they log in, and a tester can still replace either key with their own from the cockpit settings (#250). For now the seeded keys are kept on a small spending cap and rotated, since they sit on a tester machine next to the other per-tester secrets. A more isolated option, where these keys stay on the admin machine and testers reach the models through it so a key never lands on a tester machine (the way the shared embedder and voice already work), is left as a later step. This comment is the build plan, not a close.

Signed-by: mik-tf mik-tf@noreply.invalid

Plan for the email and key setup in part 2. We will add one Service setup panel to the deployer admin dashboard so an operator can set the service keys from the browser instead of by hand on the server. It covers the Resend email key with the from address and from name (the welcome-email sender bullet above), and we are extending it in the same panel to also hold the default OpenRouter and Kimi keys a new tester should start with, which keeps with the goal of having the whole sandbox configurable from one place. Every key field is write-only, so the panel shows only whether a key is set and never the value, and saving stores the values in the hero_proc secret store. The welcome-email sender will read its config live when it sends, so a change from the panel takes effect on the next email without a server restart. When a tester is provisioned, the install step seeds that tester with the default OpenRouter and Kimi keys so the assistant works as soon as they log in, and a tester can still replace either key with their own from the cockpit settings (https://forge.ourworld.tf/lhumina_code/home/issues/250). For now the seeded keys are kept on a small spending cap and rotated, since they sit on a tester machine next to the other per-tester secrets. A more isolated option, where these keys stay on the admin machine and testers reach the models through it so a key never lands on a tester machine (the way the shared embedder and voice already work), is left as a later step. This comment is the build plan, not a close. Signed-by: mik-tf <mik-tf@noreply.invalid>

mik-tf referenced this issue from a commit

2026-06-06 18:52:14 +00:00

feat(deployer): set email sender and default Kimi key from the admin dashboard

mik-tf referenced this issue from a commit

2026-06-06 22:01:04 +00:00

feat(deployer): per-tester assistant key seeding and welcome email controls

mik-tf referenced this issue from a commit

2026-06-06 22:57:35 +00:00

feat(deployer-admin): navbar plus dedicated Service setup page, honest per-tester key checkboxes

mik-tf referenced this issue from a commit

2026-06-06 23:59:29 +00:00

feat(deployer-admin): add an admin Manual page