pastilhasandClaude Opus 5
417e091dfe
two fixed panels could show two of NPM's seven sections and had nowhere to put the other five. now the left column is the section list — proxy hosts, redirections, streams, 404 hosts, access lists, certificates, connection — and the right renders whichever is chosen. NPM's own vocabulary, in NPM's own order. somebody who has used it should find the same words, and somebody who has not will end up in NPM's UI eventually anyway; better names would just mean learning both. "404 hosts" reads oddly and is theirs, so the hint under it says what it means. the two panels never speak. the nav writes ?section= and the detail pane reads it — navigation-audit's rule, and it is what makes a section linkable and survive a reload. changing section clears ?host=, which belonged to the list that was open. three things folded up while doing it. the unconfigured check moved to the detail pane and happens once, so all seven sections say "no connection yet" the same way instead of six saying it badly. the settings gear is gone: connection is a nav row now. and the four list-only sections are one component, differing only in what a row says — proxy hosts and certificates stay separate because they have real behaviour, and folding them in would be a props bag that is a worse version of both. the counts in the nav are one request each. affordable against a local NPM, and they answer "is this worth opening" without a click. a count that fails is absent rather than zero — zero is a fact about NPM, a failure is a fact about the request, and the detail pane reports that properly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
44 lines
2.0 KiB
TypeScript
44 lines
2.0 KiB
TypeScript
import type { LayoutNode } from 'officerdev';
|
|
|
|
// A nav down the left, whatever it selects beside it, a chat across the bottom.
|
|
//
|
|
// ── The chat panel is ours; the chat inside it is the platform's ──
|
|
//
|
|
// Naming `officerdev/chat` here does NOT work, and the way it fails is quiet: `PluginScreen` renders the
|
|
// workspace with `appTypes={{ allowed, fallback: allowed[0] }}` where `allowed` is this plugin's own panel
|
|
// keys, so an unrecognised appType becomes the FIRST panel — which is how this layout briefly rendered two
|
|
// Hosts panels. The shared registry and the layout allow-list are different things.
|
|
//
|
|
// So `proxy-manager-chat` is our panel and `EmbeddableChat` inside it is the platform's component. No
|
|
// second chat to maintain, and nothing for the allow-list to reject.
|
|
//
|
|
// The chat gets a third of the HEIGHT rather than a column, because a conversation reads badly narrow and
|
|
// a list does not. The nav is the narrow one: it holds seven rows of two short lines and nothing grows.
|
|
//
|
|
// ── What makes the chat useful HERE ──
|
|
//
|
|
// Nothing in this layout. The agent gets the `Proxy Manager` skill the same way it gets every other one —
|
|
// from this plugin's `skills/` directory, offered in every conversation on the machine, costing two lines
|
|
// until something actually needs it. A chat in this panel is an ordinary chat that happens to be sitting
|
|
// underneath the thing it is being asked about.
|
|
export const defaultLayout: LayoutNode = {
|
|
type: 'group',
|
|
id: 'proxy-manager-root',
|
|
direction: 'vertical',
|
|
children: [
|
|
{
|
|
node: {
|
|
type: 'group',
|
|
id: 'proxy-manager-top',
|
|
direction: 'horizontal',
|
|
children: [
|
|
{ node: { type: 'panel', id: 'proxy-manager-nav', appType: 'proxy-manager-nav' }, size: 30 },
|
|
{ node: { type: 'panel', id: 'proxy-manager-detail', appType: 'proxy-manager-detail' }, size: 70 },
|
|
],
|
|
},
|
|
size: 66,
|
|
},
|
|
{ node: { type: 'panel', id: 'proxy-manager-chat', appType: 'proxy-manager-chat' }, size: 34 },
|
|
],
|
|
};
|