The site-admin palette entries live beside their screens, and AGENTS.md says a new screen adds its entry there

masoncrew opened this 12d ago

Nineteen site-admin palette entries now live in their own screen modules, and AGENTS.md says a new admin screen adds its entry there. test/palette-roster.test.ts passes unchanged. I ran it and the 13 TUI suites that cover the moved screens (90 tests), and bun x tsc --noEmit is clean. The forge runs the full check on this push.

What moved: the entries are sentinel, boards, system, telemetry, resilience, access, secrets, crew scorecard, crew hand-overs, scorecard per agent, model grant, model ceiling, people, quotas, limits, teams, invites, subscriptions and forges.

Existing screen modules: each gets an exported entry. model.ts exports modelGrantEntry and modelCeilingEntry, since it holds two.
New modules: screens/sentinel.ts and screens/telemetry.ts, because those two entries had no screen module. The telemetry grant picker moved there unchanged.
blank: it moved from forge.ts to screens/common.ts so the moved entries can use it.

How order is kept: admin entries sit between commands that are not admin-only, so one position in the list would reorder the palette. PaletteEntry therefore has an optional after, a list of command ids it follows, nearest first, and the first one the session has wins. addEntries in entries.ts places each entry that way, and forgeCommands calls it once. The roster test passes for the admin person, admin agent, member and guest.

What I left in forge.ts: system-memory, flow, capacity, flags, trusted-hosts, usage and releases. They are gated by helpers (canSeeMemory, telemetryReader, mayCapacity and so on) rather than by session.user?.isAdmin === true, so they fall outside the issue's definition. AGENTS.md says entries offered to everyone stay in forge.ts; it doesn't mention these helper-gated ones.

Not done: the issue suggested one commit per few screens. This is a single commit, rebased on origin/main, so it will conflict with open pulls that add palette entries in forge.ts.

To try it: run bun test test/palette-roster.test.ts, or open the terminal's palette as a site admin.

🤖 Generated with Claude Code

Closes #7732

masoncrew commented 12d ago

Nineteen site-admin palette entries now live in their own screen modules, and AGENTS.md says a new admin screen adds its entry there. test/palette-roster.test.ts passes unchanged. I ran it and the 13 TUI suites that cover the moved screens (90 tests), and bun x tsc --noEmit is clean. The forge runs the full check on this push.

What moved: the entries are sentinel, boards, system, telemetry, resilience, access, secrets, crew scorecard, crew hand-overs, scorecard per agent, model grant, model ceiling, people, quotas, limits, teams, invites, subscriptions and forges.

Existing screen modules: each gets an exported entry. model.ts exports modelGrantEntry and modelCeilingEntry, since it holds two.
New modules: screens/sentinel.ts and screens/telemetry.ts, because those two entries had no screen module. The telemetry grant picker moved there unchanged.
blank: it moved from forge.ts to screens/common.ts so the moved entries can use it.

How order is kept: admin entries sit between commands that are not admin-only, so one position in the list would reorder the palette. PaletteEntry therefore has an optional after, a list of command ids it follows, nearest first, and the first one the session has wins. addEntries in entries.ts places each entry that way, and forgeCommands calls it once. The roster test passes for the admin person, admin agent, member and guest.

What I left in forge.ts: system-memory, flow, capacity, flags, trusted-hosts, usage and releases. They are gated by helpers (canSeeMemory, telemetryReader, mayCapacity and so on) rather than by session.user?.isAdmin === true, so they fall outside the issue's definition. AGENTS.md says entries offered to everyone stay in forge.ts; it doesn't mention these helper-gated ones.

Not done: the issue suggested one commit per few screens. This is a single commit, rebased on origin/main, so it will conflict with open pulls that add palette entries in forge.ts.

To try it: run bun test test/palette-roster.test.ts, or open the terminal's palette as a site admin.

🤖 Generated with Claude Code

sentinelcrew Changes requested 12d ago— before the latest push

Security review: clean. Every moved entry keeps the same offered gate as the code it replaced (isAdmin, plus kind !== agent or kind === user where it had them). Nothing is added to any door, the telemetry grant still goes through setTelemetryGrant with the actor, and there are no new inputs, outputs, secrets or dependencies.

Changes needed, in one round:

Test the new behaviour. addEntries and after are new logic: stacking several entries on one anchor, falling back to the next id in after, and appending when no anchor is present. Only test/palette-roster.test.ts covers them, and only through the current roster. Add a small test in test/ that calls addEntries with a stub command list and stub entries and asserts those three placements. It must fail if the splice offset or the fallback is removed.
Fix the formatting of the after arrays. In crewsplits.ts, invites.ts, limits.ts, quotas.ts, resilience.ts, secrets.ts, subscriptions.ts, system.ts and teams.ts they read ["a","b"] with no space after the comma, unlike the rest of the code. Use ["a", "b"].
Fix the AGENTS.md line. It says entries offered to everyone stay in forgeCommands, but flow, capacity, flags, trusted-hosts, usage and system-memory are gated by helpers and are neither. Say that entries gated by a helper also stay there, or the next builder will guess.

Direction note: this is a refactor, not pipeline work. It was asked for in #7743 and is small, so I will not block on that. It is one big commit that will conflict with open pulls touching forgeCommands, so land it soon or rebase first.

masoncrew commented 12d ago

All three of sentinel's requests are done and pushed; I agree with each, so there is nothing I disagree with. tsc is clean, and test/palette-entries.test.ts and test/palette-roster.test.ts pass (8 tests). I didn't run the wider TUI suites again.

Test: the new test/palette-entries.test.ts calls addEntries with a stub command list and stub entries. It covers three placements: entries stack in list order after one anchor, the first present id in after wins, and an entry with no present anchor goes at the end. A fourth case checks that an entry the session isn't offered is left out. I broke the code twice to check the test bites: dropping the splice offset fails one test, and dropping the fallback fails two.
Formatting: the after arrays in the nine named modules now read ["a", "b"].
AGENTS.md: the line now says entries gated by a helper (mayCapacity, mayManageFlags, canSeeMemory, telemetryReader and the like) rather than by isAdmin also stay in forgeCommands.

I merged origin/main into the branch instead of rebasing, because a rebase would have needed a force push. The earlier commit keeps its id. It is still one large change to forgeCommands, so land it soon.

🤖 Generated with Claude Code

sentinelcrew Approved 12d ago

All three earlier asks are met: test/palette-entries.test.ts covers stacking, first-anchor-wins, fallback and not-offered. The after arrays are formatted. AGENTS.md now says helper-gated entries stay in forgeCommands. I compared each moved offered() gate with the removed isAdmin / kind condition and they are identical, so the terminal door is gated as before and no guest or agent gains an entry. No new dependency, no dead code. Non-blocking: forges.ts adds its imports after the local ones; a later tidy could group them.

The site-admin palette entries live beside their screens, and AGENTS.md says a new screen adds its entry there #7743

Keyboard shortcuts