Skip to content

Make the admin screens show and say what they are asking - #32

Open
davidmckayv wants to merge 2 commits into
mainfrom
feat/component-preview
Open

Make the admin screens show and say what they are asking#32
davidmckayv wants to merge 2 commits into
mainfrom
feat/component-preview

Conversation

@davidmckayv

Copy link
Copy Markdown
Contributor

What this changes

The Components page listed a name, an identifier and a paragraph, and asked an administrator to decide from that whether a Bot should be allowed to answer with it. The question they arrive with, what does this actually put in front of a person, was the one thing the page could not answer.

Each component now introduces itself. See it draws the real component, from preview props declared beside its own definition, so a new component cannot be added without deciding how it shows itself and a preview cannot drift from the thing it previews.

Closed by default: this is a list an administrator scans, and thirteen components drawn at once is a page nobody reads.

Taken from CopilotKit/openkai. Only the applicable half, the preview and the admin disclosure, not the visitor demo it was originally built for. Our extra admin surfaces, Computers in particular, are untouched.

Notes on the port

  • Props, not tool arguments. For a component that suspends a run those are not the same thing: it is handed the whole interaction, { status, args, respond }, and would throw on arguments alone.
  • A component with nothing to preview says so rather than drawing an empty frame. That is the honest answer for the two that read this deployment's own audit records and have nothing to draw until a Bot asks.
  • 12 of the 14 components gained preview props. showActivityReport and showRefused are the two that read live records.

Where it runs

  • New state that outlives a request? None. Rendering only, from constants in the bundle.
  • What happens on the second replica? Nothing. No server involvement.
  • Anything serialised? No.
  • Anything fanned out to a browser? No.
  • New listener, port, or schedule? None.

Boundary and audit

  • No change to any acting path. Nothing here calls a tool or reaches a vendor.
  • The preview respects publication and grants: it renders what the deployment reports, not what the build contains, so an unpublished or withheld component is not advertised.

Proof

Driven in Chrome at /admin/components.

  • showMetrics draws the real card: "This month", Revenue $412k with "+12% on last month" in positive tone, Open deals 38, Churn 1.4% with "+0.3pt" in caution tone.
  • showPieChart draws a real SVG donut with its legend and percentages, Build 48% / Support 26% / Meetings 26%.
  • showActivityReport says "Draws this deployment's own records, so it has nothing to show until a Bot asks for it" instead of an empty frame.
  • Every row has the disclosure, and all of them are closed on load.

format:check, lint, typecheck clean. 647 pass, 5 skip, 0 fail.

The Components page listed a name, an identifier and a paragraph, and asked somebody to decide from
that whether a Bot should be allowed to answer with it. The one question they arrived with, what
does this put in front of a person, was the one thing the page could not answer.

Each component now introduces itself. `See it` draws the real component, from props it carries
beside its own definition, so a new component cannot be added without deciding how it shows itself
and a preview cannot drift from what it is previewing.

Closed by default. This is a list an administrator scans, and thirteen components drawn at once is a
page nobody reads.

Props rather than tool arguments, because for a component that suspends a run those are not the same
thing: it is handed the whole interaction, `{ status, args, respond }`, and would throw on arguments
alone. A component with nothing to preview says why rather than showing an empty frame, which is the
honest answer for the two that draw this deployment's own records and have nothing to draw until a
Bot asks.

Taken from CopilotKit/openkai. Only the applicable half: the preview and the admin disclosure, not
the visitor demo it was built for.
Three places where the interface named a thing and then relied on somebody already knowing what it
was.

"May read" sat under a row of Bot names, in the same shape as the row above it, and is a different
kind of grant entirely: the row above decides which Bots may draw a component, this decides what
that component may go and fetch in order to draw itself. Read as one switch, an administrator grants
a component to every Bot believing that is all they did. Both rows now say which question they are
answering, and the Bot row says what switching one off actually does, which is that the Bot is never
told the component exists rather than being told no.

The boundary's deny list said "It may never" and offered a CEL box with one example in it. Nothing
named the vocabulary, so writing a second rule meant reading the source. The section now lists what
an expression may ask about, and says the thing an operator most needs to know before typing:
a rule that cannot be evaluated counts as a match, so a mistyped deny refuses rather than quietly
permitting what it was meant to forbid.

"changes things" beside a tool reads as a description of the tool. It is not: it is the effect the
boundary evaluates as `mcp.effect`, and anything not positively known to be read-only gets it, which
is every tool on a server somebody added by URL. That is a governance default nobody could see.

None of this is new behaviour. All of it was already true and none of it was on screen.
@davidmckayv davidmckayv changed the title Show an administrator what a component grant actually draws Make the admin screens show and say what they are asking Aug 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant