@burdenoff/microfe-vibecontrols 2026.915.3 → 2026.924.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -20,7 +20,6 @@ var e = [
|
|
|
20
20
|
"Stop a session I no longer need",
|
|
21
21
|
"List my recent sessions"
|
|
22
22
|
],
|
|
23
|
-
requiresAdmin: !0,
|
|
24
23
|
writeCapable: !0
|
|
25
24
|
},
|
|
26
25
|
{
|
|
@@ -32,8 +31,7 @@ var e = [
|
|
|
32
31
|
"What is the plugin manifest structure?",
|
|
33
32
|
"Explain the plugin lifecycle hooks",
|
|
34
33
|
"Show me a plugin example with frontend UI"
|
|
35
|
-
]
|
|
36
|
-
requiresAdmin: !0
|
|
34
|
+
]
|
|
37
35
|
}
|
|
38
36
|
], t = "assistant";
|
|
39
37
|
function n(t) {
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"assistantUsecases.js","names":[],"sources":["../../src/config/assistantUsecases.ts"],"sourcesContent":["/**\n * VibeControls AI assistant modes.\n *\n * ★ These are the modes the shared fe-libs panel OFFERS. The
|
|
1
|
+
{"version":3,"file":"assistantUsecases.js","names":[],"sources":["../../src/config/assistantUsecases.ts"],"sourcesContent":["/**\n * VibeControls AI assistant modes.\n *\n * ★ These are the modes the shared fe-libs panel OFFERS. The first switch into a\n * `writeCapable` mode opens the one-time consent dialog, enforced in fe-libs\n * (`shared/assistant/ui/AssistantChatArea`); what is decided HERE is which modes\n * carry that flag. Same mechanism as HealthyBowl's `assistantUsecases.ts`.\n *\n * ★★★ NO MODE IS ADMIN-GATED (BOFF-7800). Every mode is offered to every\n * member, and RBAC alone decides what any of them may actually do. The decision:\n * \"Allow anyone to use any mode keeping auto as default — but RBAC will control\n * everything behind the scenes. If they can't do something, RBAC won't allow.\"\n *\n * ★★ The gate this replaces was asking the wrong question at the wrong scope.\n * It read the caller's role at the ACTIVE ORG (`myRoles` via\n * `getOrganizationId()`), while product writes are governed by the WORKSPACE\n * scope — so a workspace Editor, whom the server already permits, was refused\n * by the UI for being an org Viewer. Verified server-side: `sandbox:create` is\n * granted to Editor and above (wspace-rbac-svc seed-unified-rbac.ts:5836-5842),\n * so this exposes what the server already allows rather than granting anything.\n * A workspace Viewer is still refused — by RBAC, where the refusal belongs, and\n * it now reads as a permission answer rather than a malfunction (fe-libs #259).\n *\n * assistant \"Ask\". Every member. The sandbox runs with\n * AI_ASSISTANT_READONLY, so its GraphQL helper refuses mutations.\n * api-calls \"Take action\". Admins only. Writes through the gateway, and\n * the sandbox runs with AI_ASSISTANT_CONFIRM_WRITES, so each\n * write waits for the user's approval.\n * vibe-plugins \"Build\". Admins only. Builds plugin artifacts, but its sandbox\n * is NOT read-only; see the note on BUILD below. Not flagged\n * `writeCapable` (yet), for the reason given there.\n *\n * ★★ `general` is gone. A stored `general`, or any mode not listed here, lands\n * on Ask; see `resolveOfferedMode` and `useOfferedAssistantMode`.\n *\n * ★ The mode IDs are transport values and must not be renamed: they choose the\n * sandbox image, its environment and the agent's persona. Only labels change.\n */\n\nexport interface AssistantUsecase {\n id: string;\n label: string;\n description: string;\n suggestions: readonly string[];\n /**\n * ★★★ DELIBERATELY UNSET ON EVERY MODE (BOFF-7800). The field remains because\n * fe-libs still reads it, and declaring it is what switches the org-role check\n * back on — `useAssistantApiAccess` derives `hasAdminGatedMode` from exactly\n * this flag, so one `requiresAdmin: true` here silently restores the gate and\n * fires a `myRoles` query on every session. A test asserts no mode sets it.\n */\n requiresAdmin?: boolean;\n /** Can change live data, so the consent dialog and the composer's write-access warning apply. */\n writeCapable?: boolean;\n}\n\n/**\n * \"Ask\": read-only, for everyone.\n *\n * ★★ The copy must not promise a write. This mode's sandbox refuses every\n * mutation, so \"Create a new vibe called demo\", the suggestion it used to carry,\n * could only ever end in a refusal after the user had waited for a sandbox.\n * `assistantUsecases.test.ts` fails on write verbs anywhere in this copy.\n */\nconst ASK = {\n id: 'assistant',\n label: 'Ask',\n description:\n 'Ask about VibeControls and your workspace. It reads your vibes, sessions and agents, explains what you are looking at and points you to the right page. Read-only.',\n suggestions: [\n 'What can I do on this screen?',\n 'List my recent sessions',\n 'Where do I manage my agents?',\n 'How do tunnels work?',\n ],\n} as const satisfies AssistantUsecase;\n\n/** \"Take action\": the write mode. Admin-only, consent on first switch, approval per write. */\nconst TAKE_ACTION = {\n // Display label only; the mode ID stays 'api-calls'.\n id: 'api-calls',\n label: 'Take action',\n description:\n 'Let the assistant make changes for you: create vibes, rename them, stop sessions. It shows you each change and waits for your approval before anything is saved.',\n suggestions: [\n 'Create a new vibe called demo',\n 'Rename one of my vibes',\n 'Stop a session I no longer need',\n 'List my recent sessions',\n ],\n writeCapable: true,\n} as const satisfies AssistantUsecase;\n\n/**\n * \"Build\": Vibe Plugin authoring. Admin-only.\n *\n * ★★ Why admin-only, when its job is producing plugin files: the sandbox is\n * not confined to that job, and can write.\n * - fe-libs forwards the user's own access and workspace tokens on EVERY proxy\n * request, whatever the mode (`shared/assistant/api.ts`, `proxyToSandbox`).\n * - wspace-sandbox-svc passes them into the sandbox for every assistant mode\n * (`ensureAssistantProxyAccess`, `X-AI-Assistant-Auth-Token`).\n * - ai-assistant keeps them whenever the sandbox holds no delegated app\n * credentials, which `vibe-plugins` never does (proxy-token auth), and its\n * GraphQL helper then authenticates as the user (`api-auth.ts`).\n * - The mode has `bash`, the gateway URLs are in its environment, and it gets\n * NEITHER brake: AI_ASSISTANT_READONLY is set only for `assistant`,\n * AI_ASSISTANT_CONFIRM_WRITES only for `api-calls`.\n * So it can change workspace data within the user's own permissions, and\n * decision D4 makes every such mode admin-only.\n *\n * ★★ Why NOT `writeCapable`, although it can write: in fe-libs (2026.914.3 and\n * earlier) that flag routes the first switch into the mode through\n * `AssistantApiCallsConsentDialog`, whose copy is written for Take action only.\n * It is titled \"Switch to Take action mode?\", its button reads \"Enable Take\n * action\", and it promises the assistant will ask before making a change. For\n * Build all three are false: no AI_ASSISTANT_CONFIRM_WRITES, no confirm\n * preamble. Its one `apiCallsAcknowledged` flag also covers every\n * `writeCapable` mode, so accepting it from Build would skip Take action's real\n * consent. Showing no dialog is more honest than showing that one. The cost:\n * the composer's write-access warning (`writeAccessDenied`) no longer shows in\n * Build. Restore the flag once fe-libs words the dialog, and keeps the\n * acknowledgment, per mode; `assistantUsecases.test.ts` fails when the dialog\n * stops naming Take action, as a reminder.\n *\n * ★ The flags gate the UI; they add no sandbox brake. That is why this copy\n * claims no approval step for the mode: the sandbox does not enforce one.\n */\nconst BUILD = {\n id: 'vibe-plugins',\n label: 'Build',\n description:\n 'Build a Vibe Plugin that extends VibeControls. The assistant scaffolds and compiles it from the platform guides and gives you the files to download.',\n suggestions: [\n 'How do I create a new Vibe Plugin?',\n 'What is the plugin manifest structure?',\n 'Explain the plugin lifecycle hooks',\n 'Show me a plugin example with frontend UI',\n ],\n} as const satisfies AssistantUsecase;\n\nexport const ASSISTANT_USECASE_CONFIG = [ASK, TAKE_ACTION, BUILD] as const;\n\nexport type AssistantUsecaseId = (typeof ASSISTANT_USECASE_CONFIG)[number]['id'];\n\n/**\n * Where a user lands when their mode is not offered.\n *\n * ★ The same literal fe-libs falls back to (`AssistantChatArea` resets to\n * `\"assistant\"` once the role check settles). Typed as a mode ID, so removing\n * Ask from the list above fails the typecheck here.\n */\nexport const DEFAULT_ASSISTANT_MODE: AssistantUsecaseId = 'assistant';\n\nfunction isOfferedMode(mode: unknown): mode is AssistantUsecaseId {\n return ASSISTANT_USECASE_CONFIG.some((config) => config.id === mode);\n}\n\n/**\n * The mode to use for a stored one: itself when this product offers it, Ask\n * when it does not (a retired `general`, another product's mode, a corrupt\n * value).\n *\n * ★ It answers only \"does this mode EXIST here\". Whether the user may use an\n * admin-only mode is the role check's question and stays with fe-libs: resetting\n * an admin's stored Take action here, before `myRoles` answers, would throw them\n * out of that mode on every reload.\n */\nexport function resolveOfferedMode(mode: unknown): AssistantUsecaseId {\n return isOfferedMode(mode) ? mode : DEFAULT_ASSISTANT_MODE;\n}\n"],"mappings":"AA6IA,IAAa,IAA2B;CA7E5B;EACV,IAAI;EACJ,OAAO;EACP,aACE;EACF,aAAa;GACX;GACA;GACA;GACA;GACD;EACF;CAGmB;EAElB,IAAI;EACJ,OAAO;EACP,aACE;EACF,aAAa;GACX;GACA;GACA;GACA;GACD;EACD,cAAc;EACf;CAqCa;EACZ,IAAI;EACJ,OAAO;EACP,aACE;EACF,aAAa;GACX;GACA;GACA;GACA;GACD;EACF;CAEgE,EAWpD,IAA6C;AAE1D,SAAS,EAAc,GAA2C;AAChE,QAAO,EAAyB,MAAM,MAAW,EAAO,OAAO,EAAK;;AAatE,SAAgB,EAAmB,GAAmC;AACpE,QAAO,EAAc,EAAK,GAAG,IAAO"}
|