total-recall-brain 3.45.0 → 3.46.0

package/scaffold/.agent/skills/plugin/evals/cases/04-card-collects-credential.mjs

@@ -1,47 +0,0 @@
-/**
- * A card that collects an API key in a password field.
- *
- * Observed: the scaffolder generated exactly this, dispatching the raw value
- * as a `save-token` event — a second credential store and a leak surface.
- */
-const CARD = `
-export class CollectingCard extends HTMLElement {
-  connectedCallback() {
-    const root = this.attachShadow({ mode: 'open' })
-    const input = document.createElement('input')
-    input.type = 'password'
-    input.setAttribute('aria-label', 'API key')
-    const button = document.createElement('button')
-    button.textContent = 'Save'
-    button.addEventListener('click', () => {
-      this.dispatchEvent(new CustomEvent('save-token', { detail: { token: input.value }, bubbles: true }))
-    })
-    root.append(input, button)
-  }
-}
-customElements.define('tr-collecting-card', CollectingCard)
-`;
-
-export default {
-  name: 'card-collects-credential',
-  why: 'one credential path exists in the system, and it is the auth plugin',
-  files: {
-    'plugin.json': JSON.stringify({
-      id: 'collecting', name: 'Collecting', version: '1.0.0', description: 'A plugin whose card collects a key.',
-      reuse: { commands: ['total-recall auth secret'], owned: 'Provides the service connection screen.' },
-      cli: { command: 'collecting', handler: './cli.mjs', subcommands: [
-        { name: 'status', effect: 'read' },
-        { name: 'token', effect: 'write', args: [{ name: 'key', label: 'Key', type: 'string', secret: true }] },
-      ] },
-      secrets: [{ key: 'COLLECTING_API_KEY', description: 'Service key', required: true }],
-      status: { command: 'status', refresh_seconds: 30 },
-      branding: { color: '#6366f1' },
-      ui: { elements: [{ id: 'card', kind: 'card', tag: 'tr-collecting-card', module: 'ui/card.js' }] },
-    }, null, 2),
-    'cli.mjs': "import { spawnSync } from 'node:child_process'\nspawnSync('total-recall', ['auth', 'secret', 'get', 'COLLECTING_API_KEY'])\nexport default async function run() {}\n",
-    'ui/card.js': CARD,
-  },
-  expect: {
-    fail: ['never collects a credential', 'never transmits a credential'],
-  },
-};

package/scaffold/.agent/skills/plugin/prompts/06-card.md

@@ -1,46 +0,0 @@
-# Prompt 6 — Design the card face by hand
-
-Every plugin has a card face. It is bespoke owner code, written for this plugin and no other.
-
-Full specification: [card](../references/card.md).
-
-## The prompt
-
-Work in this order. Write the reasoning into `ui/DESIGN.md` **before** writing component code.
-
-1. Who uses it, and what are they in the middle of doing? Name the real tasks.
-2. What must be visible without a single click? That decides the hierarchy.
-3. What is the one primary action, and what is destructive?
-4. What is the domain's own vocabulary? Use it. Never render a domain as "a list of commands".
-5. Then choose the arrangement, and justify it in the plugin's own terms.
-
-Then author `ui/card.js`:
-
-- **One bespoke Web Component**, declared as the single element of kind `card` in `ui.elements`. No `card_layout`, no template name, no region or widget vocabulary.
-- **Screens the plugin defines**, ordered by the plugin's own tasks, most-used first. Never one screen per subcommand.
-- **Wide, not a column.**
-- **Real data only.** Every value from `host.run(subcommand, args)`. Anything not returned renders an em dash with its reason.
-- **Failures are states**, each rendered explicitly with the time of the last attempt.
-- **Name a value's driver** when severity combines several measures, or a red tile beside a green figure reads as a contradiction.
-- **The host's tokens.** The dashboard is dark: use the injected `--text-*`, `--bg-*`, `--border`, `--accent` and your brand tokens. Declare state colours once in a `:host` block and keep them legible on dark.
-- **Accessible**: 44 px controls, keyboard reachable, visible focus, contrast-checked states, `prefers-reduced-motion` respected.
-- **Severity never by colour alone** — pair every colour with a word.
-- **The card consumes credentials, never collects them.**
-
-## Correct means
-
-1. Render at **360, 768 and 1280 px** — no horizontal overflow anywhere.
-2. Render on the **real dashboard tokens** (dark), not on a white page.
-3. Exercise every state: credential present, missing, provider unreachable, call rejected, empty, stale.
-4. Put it beside another plugin's face. If you cannot tell which is which from the layout alone, it is not finished.
-5. No secret value can reach the DOM in any state.
-
-**Then look at it.** Every defect in the anti-patterns catalogue that begins "only looking reveals" was invisible to a schema check.
-
-## Check
-
-```
-node <skill>/scripts/record.mjs . --card
-```
-
-Then render and inspect it yourself. A passing check is not a design.

package/scaffold/.agent/skills/plugin/references/card.md

@@ -1,90 +0,0 @@
-# The card face
-
-Every plugin has a card face. It is the plugin's interface in the Total Recall dashboard, and it is **bespoke owner code**: written by hand, for that one plugin, from that plugin's own function and brand.
-
-There is no template, no layout vocabulary, no widget set, no region list. Core rejects `card_layout` outright. A face that could be dropped onto a different plugin is a failed face.
-
----
-
-## What the host provides, and nothing more
-
-- a **sandboxed frame** — opaque origin, `default-src 'none'`, `connect-src 'none'`, no dashboard DOM and no storage
-- a frozen **`host`** object whose `run(subcommand, args, options)` is the only channel out
-- the **design tokens** it injects into the frame
-- the **drawer**, which carries settings and credentials so the face stays focused
-
-Everything else — structure, vocabulary, hierarchy, controls, visual language — is yours to design for this plugin and no other.
-
-## The design process
-
-Work in this order, and write the reasoning into `ui/DESIGN.md` **before** writing component code.
-
-1. **Who uses it, and what are they in the middle of doing?** Name the two or three real tasks. A payments operator reconciling a payout is not the same as one hunting a suspicious charge.
-2. **What must be visible without a single click?** That decides the hierarchy. A DNS plugin shows the zone and its records; a telephony plugin shows line state and the active call; a telemetry plugin shows which machine is struggling.
-3. **What is the one primary action, and what is destructive?** A destructive action gets confirmation, and never the visual weight of the obvious next step.
-4. **What is the domain's own vocabulary?** Use it. Amounts, dates and states in the arrangement an accountant expects; peers, routes and reachability for a mesh. Never render a domain as "a list of commands".
-5. **Then choose the arrangement**, and justify it in the plugin's own terms.
-
-`ui/DESIGN.md` carries a real `tokens:` block matching the manifest, and the reasoning above. See the surfaces reference for the token fields.
-
-## Screens
-
-A plugin with several jobs carries them across **screens the operator flips through**. The plugin defines them.
-
-- Order them by the plugin's own tasks, **most-used first**.
-- The first screen answers what the operator opened the card to do.
-- **Never one screen per subcommand.** That is the host's command list wearing a costume, and it is what makes unrelated plugins look alike.
-- Never a screen set the host derives or imposes.
-
-## Rules that make a face real
-
-- **Real data only.** A value appears only if a command or the host returned it. Never a seeded reading, a placeholder, an example default or an `ONLINE` badge. If a source fails, show the failure and when it was last attempted.
-- **Unknown is an em dash with a reason**, never a zero and never a reassuring word. `0 unpushed commits` and `unknown, no upstream configured` are different facts.
-- **Failures are states**, first-class and rendered like any other. Missing credential, unreachable provider, rejected call, stale reading.
-- **A value's driver is named.** If severity combines several measures, say which one drove it, or a red tile beside a green figure reads as a contradiction.
-- **Every declared operation is reachable**, and its effect is visible — a `read` must not look like a `send`.
-- **Destructive actions state their target and require confirmation.**
-- **The card consumes credentials, never collects them.** Report present or missing; never render a value; never render an input that accepts one. Hand over the auth command to run instead.
-- **Tokens only.** No hard-coded hex outside the single `:host` token block. The dashboard is **dark**, so the injected `--text-*`, `--bg-*`, `--border` and `--accent` values are light-on-dark; tune your state colours for that surface and keep them legible.
-- **Wide, not a column.** A narrow column forces vertical stacking, which is what makes different plugins look alike.
-- **Severity never by colour alone** — pair every colour with a word.
-- **Accessible.** Controls at least 44 px, keyboard reachable, visible focus, contrast-checked state colours, `prefers-reduced-motion` respected.
-- **No decoration.** No ambient animation, no emoji as icons, no hardware-skin imitation, no fake equaliser on a plugin that has no audio. Motion only when it reports a state change.
-- **Copy.** No filler words, and no sentence ends with a preposition.
-
-## Shape of the component
-
-```js
-export class ExampleCard extends HTMLElement {
-  get screens() { return [ { id: 'charge', label: 'Charge' }, /* … most-used first */ ] }
-  connectedCallback() { /* attach shadow, render frames with em dashes, then read */ }
-  disconnectedCallback() { /* clear timers; never leave one running */ }
-  async read() { /* host.run(...) → paint; a rejection clears figures and shows the error */ }
-}
-if (!customElements.get('tr-example-card')) customElements.define('tr-example-card', ExampleCard)
-```
-
-- Values are painted **after** a command returns. Before the first read, the frames show em dashes.
-- A failed read **clears** every figure rather than retaining the previous one as though current.
-- Timers are cleared on disconnect.
-
-## Verifying a face
-
-Run `scripts/record.mjs --card` for the mechanical checks, then look at it:
-
-1. Render at **360, 768 and 1280 px**. No horizontal overflow at any width.
-2. Render on the **real dashboard tokens** (dark), not on a white test page. A face that only reads on white is broken in production.
-3. Exercise every state: credential present, credential missing, provider unreachable, call rejected, empty, stale.
-4. Put it beside another plugin's face. If you cannot tell which is which from the layout alone, it is not finished.
-5. Confirm no secret value can reach the DOM in any state.
-
-## What a face must never do
-
-- Never seed a value, a hostname, a reading or a status word.
-- Never show a reassuring default in place of an unknown.
-- Never render a secret, in any state, for any reason.
-- Never collect a credential.
-- Never present a command name as the primary structure.
-- Never derive its screens from the command list.
-- Never style a destructive action as the obvious next step.
-- Never render as a narrow column when width is available.

package/scaffold/.agent/skills/plugin/subagents/card-designer.md

@@ -1,60 +0,0 @@
----
-name: card-designer
-inputs: a capability brief — users, tasks, what must be visible without a click, dependencies, brand
-returns: ui/DESIGN.md reasoning and a first ui/card.js, or the questions that cannot be answered yet
----
-
-# Subagent — card designer
-
-Design one plugin's card face. You are **not** filling in a layout: you are designing the interface for this capability, and it must not resemble any other plugin's.
-
-Read [card](../references/card.md) first. It is the specification.
-
-## Ask before you draw
-
-Given the brief, you must be able to answer:
-
-1. Who uses it, and what are they in the middle of doing?
-2. What must be visible without a single click?
-3. What is the one primary action, and what is destructive?
-4. What is the domain's own vocabulary?
-5. What is the worst thing that happens if the operator misreads this screen?
-
-**If you cannot answer 1, 2 or 4 from the brief, stop and return the questions.** A face designed around a guessed function is a template, which is the failure this exists to prevent. Do not invent users or tasks to proceed.
-
-## Design
-
-1. Write `ui/DESIGN.md`: who uses it, the tasks, what is visible without a click, the vocabulary, the chosen arrangement and why it fits this plugin in its own terms, the `tokens:` block, and the state list.
-2. Author `ui/card.js`: one Web Component, the single element of kind `card`, screens the plugin defines and orders by task frequency, wide not a column.
-
-## Hard rules
-
-- **No template, no `card_layout`, no region or widget vocabulary.**
-- **Every value comes from `host.run`.** Before the first read, frames show em dashes. Never a seed, never a placeholder, never an example default.
-- **A failed read clears the figures** rather than retaining a previous one as current.
-- **Unknown is an em dash with its reason.** `0` and `unknown` are different facts.
-- **Name the driver of a combined severity**, or a red tile beside a green figure reads as a contradiction.
-- **The host's tokens, tuned for a dark surface.** The dashboard is dark; verify on its real values, not on white.
-- **Severity never by colour alone.**
-- **44 px controls, keyboard reachable, visible focus, `prefers-reduced-motion`.**
-- **Never render a secret, never collect one.**
-- **Name each screen for the task it serves**, not for a command.
-
-## Before returning
-
-- Render at 360, 768 and 1280 px on the dark tokens. No horizontal overflow.
-- Render every state: present, missing, unreachable, rejected, empty, stale.
-- Put it beside another plugin's face. If the two are interchangeable, redesign.
-
-## Return
-
-```
-DESIGN.md: <the file, or the blocking questions>
-card.js: <the file>
-screens: <each screen and the task it serves>
-states rendered: <which you exercised and what you saw>
-distinguishable from: <which plugin you compared against, and how they differ>
-unverified: <what you could not check>
-```
-
-Never return a face you have not rendered and looked at.

package/scaffold/.agent/skills/total-recall/plugins/auth/ui/DESIGN.md

@@ -1,67 +0,0 @@
-# DESIGN.md — Auth & Secrets
-
-```yaml
-tokens:
-  brand-name: "Auth & Secrets"
-  wordmark: "AUTH & SECRETS"
-  color-primary: "#10b981"
-  color-background: "#064e3b"
-  color-accent: "#34d399"
-  color-ok: "#059669"
-  color-warn: "#d97706"
-  color-danger: "#dc2626"
-  font-body: "Outfit, system-ui, sans-serif"
-  font-mono: "'JetBrains Mono', ui-monospace, monospace"
-  border-radius: "8px"
-  density: "compact"
-  motion: "120ms ease-out"
-```
-
-## Who this card is for
-
-The operator and autonomous agents managing access control, cryptographic secrets, and identities across the mesh.
-
-The operator opens this card during active administration: verifying biometric passkeys, checking Google OAuth token freshness, auditing 90-day secret rotation schedules, or inspecting active session integrity.
-
-## The four tasks, in the order the card presents them
-
-| Screen | Task Frequency | Operational Rationale |
-| :--- | :--- | :--- |
-| **Passkeys** | Daily / Routine | Biometric hardware authentication via WebAuthn FIDO2. The operator checks registered authenticators and manages credential devices. |
-| **Google OAuth** | Frequent | Identity bridge accounts. The operator monitors token expiration, executes manual refreshes, and reviews account scopes. |
-| **Secrets** | Continuous | Cryptographic credential vault. The operator audits key freshness, tracks rotation deadlines, and checks provider bindings. |
-| **Audit & Sessions** | Incident / Review | Security baseline verification. The operator inspects live access sessions and reviews policy findings. |
-
-Screen ordering follows task frequency and operational urgency rather than arbitrary command taxonomy.
-
-## The core tasks
-
-1. **Verify security posture instantly** — confirm that the secrets store is sealed, zero rotation schedules are overdue, and the security audit baseline passes.
-2. **Manage biometric hardware passkeys** — inspect registered platform authenticators (Face ID, Touch ID, Windows Hello) and security keys (YubiKey), register new authenticators, and safely revoke decommissioned hardware.
-3. **Supervise OAuth tokens** — verify Google OAuth connection status, monitor token lifetime, refresh expiring credentials, and safely disconnect accounts.
-4. **Audit secret hygiene** — review key expiration dates, inspect multi-repo bindings, verify remote deployment targets, and trigger rotation workflows without exposing secret values to the DOM.
-
-## What must be visible without a single click
-
-- **Security Verdict Line:** A clear verdict ("Secure" or the count of active warnings) and timestamp of the latest verification.
-- **Passkey Count:** Total active hardware authenticators registered on the system.
-- **OAuth Status:** Connected accounts and token health status.
-- **Secrets Store Telemetry:** Total stored keys and count of overdue rotations.
-- **Baseline Audit State:** System security verification status (Passed or Flagged).
-
-## Why the layout is this layout
-
-The card face provides a wide, responsive workspace rather than a narrow column.
-
-- **Security Verdict at the Top:** The operator requires an immediate assessment. A prominent verdict line answers whether the authentication system is healthy before secondary details appear.
-- **Horizontal Task Navigation:** Four dedicated domain screens (Passkeys, Google OAuth, Secrets, Audit & Sessions) organize operations by user intent rather than raw CLI syntax.
-- **Zero Raw Secrets in DOM:** Secret values are never rendered, logged, or accepted via input fields. The interface exposes only key names, providers, fingerprints, creation timestamps, and rotation schedules.
-- **Safe Revocation Guards:** Destructive actions such as credential revocation require explicit confirmation and display prominent warning styling. Deleting the final authentication method is blocked to prevent accidental administrative lockout.
-- **Real Telemetry Only:** All figures render em dashes (`—`) until returned by the host. Zero mock responses, zero seeded numbers, and zero reassuring default strings appear in error branches.
-
-## Responsive presentation and accessibility
-
-- **Breakpoints:** Verified across mobile (360 CSS px), tablet (768 CSS px), and desktop (1280 CSS px) viewports.
-- **Host Theme Adaptation:** Injected dark-dashboard variables (`--text-primary`, `--text-secondary`, `--bg-primary`, `--bg-secondary`, `--border`, `--accent`) govern surfaces and typography.
-- **Touch Targets:** All interactive controls declare a minimum height of 44 px.
-- **Reduced Motion:** All transitions and indicators respect `prefers-reduced-motion` settings.