feat(plugins): Pianola manager-agent + plugin system + MCP tool bridge (beta)#1139
Draft
jSydorowicz21 wants to merge 131 commits into
Draft
feat(plugins): Pianola manager-agent + plugin system + MCP tool bridge (beta)#1139jSydorowicz21 wants to merge 131 commits into
jSydorowicz21 wants to merge 131 commits into
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
Pianola is a new Encore-gated autonomous manager agent that watches agent tabs, detects when an agent is awaiting the user, classifies the ask and its risk, and either auto-answers low-risk prompts from the user's rules or escalates uncertain/high-risk ones. Foundation (steps 0-1 of Plans/pianola-implementation-plan.md): - Encore flag `pianola`, off by default, end-to-end: EncoreFeatureFlags type, DEFAULT_ENCORE_FEATURES and settingsMetadata defaults, CLI encore FEATURES + aliases (auto-pilot/autopilot/pilot/manager), and a Settings -> Encore toggle. - Shared contracts in src/shared/pianola/types.ts. - Pure, I/O-free classifier: prefers a structured AwaitingInputSignal, falls back to conservative heuristics, rates risk via a focused lexicon. - Pure, safety-first policy engine: high-risk always escalates; auto-answer only on an explicit matching rule; default is escalate. - 31 classifier/policy unit tests, plus CLI alias/default coverage. Nothing consumes the flag yet, so the feature is fully inert when off. Plans/ captures the verified codebase investigation and the build plan.
Addresses all findings from the codex review of the foundation: - CRITICAL: high-risk prompts now always escalate before any rule action, so a broad `ignore` rule can no longer suppress the most important alerts. Added a regression test. - Risk lexicon extracted into pianola-risk.ts with word-boundary regexes instead of raw substrings, fixing false positives (`auth` in `author`, `token` in `tokenizer`) and adding outward-facing/destructive coverage (push/publish/ release/merge PR/deploy/email/.env/private key/payment). Boundary tests added. - Empty-match `auto_answer` rules now escalate (an auto-answer rule must narrow its scope), preventing an accidental catch-all from auto-answering everything. - Numbered-choice detection (1) .. 2) ..) implemented to match the documented behavior; trailing-question-mark check tightened to end-of-message only. - Project/tab rule scoping normalizes path separators and casing for cross-platform robustness. - PianolaDecision is now a discriminated union so `answer` only exists on an auto_answer decision. - Added a compile-time drift guard tying PianolaMessage to the web-server SessionHistoryMessage contract. Typecheck clean; 58 Pianola/encore tests pass.
Step 2 of the Pianola plan, realized as a pure detector module rather than parser hot-path surgery (more maintainable; no parser/IPC/WebSocket contract changes, and the watcher derives the signal from session-show output it already has). - pianola-awaiting-detector.ts: detectAwaitingInput(content) returns a typed AwaitingInputSignal (precedence plan_review > permission > choice > question) with extracted options (numbered and slash/bracket forms); enrichWithAwaiting Input(messages) fills it onto assistant turns immutably before classification. - The classifier already treats a present signal as authoritative (high confidence), so structured prompts now upgrade from heuristic to structured. - Tests cover each kind, option extraction, null cases, immutability, and the detector+classifier integration. Typecheck clean; 64 Pianola tests pass.
Steps 3-4 of the plan; Pianola is now runnable end-to-end from the CLI. Layering: moved the pure brain (classifier, policy, risk, awaiting-detector) from src/main/pianola to src/shared/pianola, since both the CLI watcher and the future in-app engine consume it. Tests moved alongside. Storage: - shared/pianola/storage.ts: filenames, the PianolaDecisionRecord type, and a pure rule validator (drops malformed rules so a bad hand-edit cannot break the engine). - cli/services/pianola-store.ts: reads the rules file and appends to the JSON Lines decision audit log in the Maestro config dir (shared with the desktop, no native deps). Watcher + CLI: - shared/pianola/pianola-watcher.ts: runWatchIteration ties enrich -> classify -> decide -> dispatch/record with all I/O injected, so it is fully unit tested and reusable by a future engine. Dedups by last-handled assistant message id. - cli/commands/pianola.ts: `pianola watch <tab>` polls get_session_history and acts per rules (--dry-run, --interval, --once, --agent); `pianola rules` and `pianola log` are read views. Every command hard-gates on the pianola Encore flag. Typecheck clean across all configs; 108 Pianola/encore tests pass.
Addresses the runnable-MVP review findings: - HIGH audit-before-dispatch: the watcher records the decision BEFORE sending a message (intent record), then appends the dispatch outcome under the same id. A pre-dispatch audit-write failure now fails closed (no message sent). - HIGH bounded retry: a failed dispatch no longer advances the dedup cursor, so the prompt is retried up to MAX_DISPATCH_ATTEMPTS, then Pianola gives up instead of either looping forever or skipping it forever. - HIGH injection hardening: option extraction is strict (clean short tokens; no file paths, markdown links, version numbers) and a `choice` requires real question/choice context, so prose cannot be shaped into an auto-answerable choice. The classifier reuses the same option/asking helpers (one source). - MEDIUM decision records are validated and folded by id on read, so a malformed JSONL line cannot crash `pianola log`. - MEDIUM projectPath is threaded through the get_session_history result so project-scoped rules work in the CLI watcher. - MEDIUM the watch loop now contains iteration errors (logs and continues). - LOW a malformed rules file surfaces a one-line warning instead of silently disabling all rules. - Added watcher safety tests (audit ordering, retry/give-up, fail-closed), detector false-positive fixtures, store folding/validation tests, and CLI watch tests (mocked client + dispatch). Typecheck clean across all configs; 123 Pianola/encore tests pass.
…ormed-rules guard)
Adds the single pinned Pianola agent at the top of the Left Bar, gated by the pianola Encore flag. Pianola is a real claude-code-backed agent so it chats through the existing agent system. It is excluded from normal categories and cannot be renamed, duplicated, bookmarked, moved to a group, or deleted. - types: isPianola flag on Session - usePianolaAgent: one-time creation after sessions hydrate, flag-gated - useSessionCategories: exclude Pianola from all categories - SessionList: pinned Pianola section above Starred - SessionContextMenu: guard mutating actions for Pianola
…(v2 L2-4) Turns the pinned Pianola agent into Maestro's orchestrator using the existing, tested CLI surface (the chosen action layer over MCP). - CLI: new `maestro-cli pianola add-rule` so Pianola turns a conversation into a durable watcher rule; backed by writePianolaRules (validated, atomic) in the CLI store. - Prompt: src/prompts/pianola-system.md (identity, exact CLI invocations, task-dump orchestration, and the Hybrid confirmation discipline - auto for read/observe/watch, confirm before spawning or production sends). Registered in promptDefinitions (CORE_PROMPTS, PROMPT_IDS, quick actions). - Spawn: prepareMaestroSystemPrompt appends the Pianola prompt for the isPianola agent; process.ts injects MAESTRO_CLI_JS + MAESTRO_AGENT_ID env so Pianola's Bash can reach the CLI with no PATH assumptions. Reuses the existing maestro-cli path resolver (now exported).
Phase 1 of learning-from-history, plus the earlier fixes for the broken MAESTRO_CLI_JS path and the list-agents command name. - shared/pianola/transcript-mining.ts (pure, 23 unit tests): per-format line parsers (Claude Code + Codex), decision-pair extraction reusing enrichWithAwaitingInput + classifyMessages, reply-polarity heuristic, aggregation. - cli pianola learn: crawls ~/.claude/projects + ~/.codex/sessions into a labeled decision corpus (JSON or --out file). Verified: 154 pairs from real history. - logger: diagnostic notices to stderr so they no longer corrupt CLI --json output. - cue-cli-executor: add correct ../../cli candidate so MAESTRO_CLI_JS resolves in the preserved dev layout (also fixes Cue's latent dev path). - pianola-system prompt: use 'list agents' (real subcommand), add self-correction guidance to run --help and not substitute a stale CLI.
Three fixes to the transcript miner so Phase 2 gets a cleaner, fuller corpus: 1. Scoping flags on pianola learn: --since <date> (filter by file mtime), --project <substr> and --exclude <substr> (filter by session cwd). Lets the user target representative history and drop noise. 2. Drop topic-based aggregation (the classifier's topic is a per-ask snippet, not a stable category - it produced misleading topTopics). Replaced with a risk x polarity cross-tab, which is genuinely meaningful. 3. Widen mining recall: trigger extraction on the classifier itself (structured signal OR heuristic asks) instead of double-gating on the strict structured detector. Captures prose-style asks the detector missed. Live watcher is untouched. Result on real data: 154 -> 287 pairs, 20 -> 29 sessions. 24 unit tests (added a recall test for heuristic prose asks).
Add learned decision profiles so Pianola can recall how the user decides in a given project and judge low/medium-risk agent asks the way they would, escalating high-risk regardless. - storage contract: PianolaProfileEntry/PianolaProfiles types, validatePianolaProfileEntry/validatePianolaProfiles, resolveProfile (project profile, else global fallback, else none), with a PIANOLA_PROFILE_MAX_CHARS guard on profile size - CLI store: read/write/get/set profile helpers with atomic writes - CLI commands: pianola profile (read) and pianola set-profile (write from --file or piped stdin, optional --pair-count) - pianola-system prompt: learning/onboarding flow describing how to crawl history, synthesize a profile, get user sign-off, and recall it at decision time - tests: profile entry/collection validators and resolveProfile
When a watched agent hits an ask that no rule covers and that is not high risk, the watcher now hands the decision to Pianola (an LLM agent) to judge against the user's learned per-project profile instead of escalating straight to the user. High risk always escalates; dry runs never hand off; and the watcher stays purely rule-driven when no Pianola agent is available to hand off to. - watcher: optional resolveProfile + requestJudgment deps; a handoff branch that audits intent before the side effect (mirroring the auto-answer invariant), records the escalation, and marks the prompt handled so it is not re-handed-off - CLI: wires the handoff deps only when MAESTRO_AGENT_ID is set, builds a structured handoff prompt (waiting agent, ask, profile, how to answer or escalate), and guards against handing back to Pianola itself - prompt: tells Pianola what a decision handoff is and how to act on it, and to offer a rule when it keeps making the same call - tests: handoff fires/skips correctly across risk, profile presence, rule coverage, dry-run, and missing deps; audit-before-side-effect
The Pianola section drew a bold uppercase category header plus an accent-bordered box around the single manager agent (using the ungrouped variant, which sits flush with no horizontal margin), so one pinned agent read like a whole category and looked misaligned next to Starred/Ungrouped. Render it instead as a single flat row (normal row styling) with a pin marker and a divider below, so it reads as "the manager, pinned" rather than a section. The pin marker is shown for any isPianola session.
Give Pianola two pinned, non-closable views in its workspace - a
Dashboard and its Chat - in place of the normal file/terminal/browser
tab bar (Pianola is a manager surface, not a coding workspace). The
Dashboard is the default view and badges a live count of agents waiting
on the user.
The dashboard combines two live signals - desktop session states
(busy / waiting_input / idle) and Pianola's decision audit log
(escalations, handoffs, auto-answers) - into four sections: needs your
input, working now, recently done, and recent decisions. Rows jump to
the owning agent on click. The decision data flows through the existing
pianola.getDecisions IPC; the bucket derivation is a pure, tested
function.
- uiStore: pianolaView ('chat' | 'dashboard') + setter, default dashboard
- PianolaDashboard: view, data hook (live + polled), pure deriveDashboard
- PianolaWorkspaceTabs: the pinned Dashboard|Chat strip
- MainPanel: render the strip + swap content for Pianola
- tests: deriveDashboard bucket mapping
Captures the multi-agent audit: Pianola is a strong supervisor but not an orchestrator (4/10), Maestro is not plugin-ready (3/10), the Sprint 0 safety bundle, Track A orchestrator spine, and the tiered Track B plugin system roadmap, plus the resolved scope (full orchestrator, desktop daemon, full plugin SDK).
Closes four holes that undermined the human-in-the-loop premise of the autonomous watcher: - Durable watch-state rehydration: rehydrateWatchState(records, tabId) folds the audit log to seed lastHandledMessageId before the poll loop, so a restarted watcher no longer re-answers a prompt it already handled (the prior code recreated state fresh every start). - Watcher self-stop on Encore revoke: re-read encoreFeatures.pianola each poll and break, so toggling Pianola off in Settings actually halts in-flight autonomous answering instead of running until killed. - Proactive escalation notifications: optional deps.notify on the pure watcher; the CLI fires a notify_toast (jump-session click, sourceAgent Pianola, sticky+red for high-risk) on escalate, handoff failure, and handoff timeout, so blocking asks reach the user, not just a badge. - Handoff-failure fallback + timeout: a failed handoff no longer drops the ask; it falls back to an audited user escalation + notify. A successful handoff is tracked as pendingHandoff and, if Pianola never answers within HANDOFF_TIMEOUT_POLLS, re-escalates to the user. Watcher suite: 27 tests pass. CLI + main typecheck clean; CLI rebuilt.
The pure foundation the multi-agent coordinator consumes. Nothing in Pianola previously represented a task, a dependency, or an ordering, so a task-dump fired everything at once against incomplete upstream state. - pianola-tasks.ts (pure, immutable): PianolaTask/PianolaPlan, findPlanCycle (DFS, reports the cycle), validatePlan (shape + unknown/ self/duplicate deps + cycle detection -> errors, null plan on fatal), computeReadyTasks (pending with all deps done), markTaskStatus, propagateBlocked (fixed-point cascade from failed/skipped upstream), planProgress. - storage.ts: PIANOLA_PLANS_FILENAME + PianolaPlansFile + validatePianolaPlansFile (drops malformed plans). - CLI + desktop stores: read/write/get/upsert plans (atomic temp+rename). 37 tests pass; cli + main typecheck clean.
The pure trigger the orchestrator uses to advance the DAG: detects when
a dispatched task finished or failed so dependents can start and botched
tasks are noticed. Previously the classifier only emitted question|
blocked|none, so there was no done/failed signal at all.
- pianola-completion-detector.ts (pure): detectTaskOutcome({previousState,
currentState, recentMessages}) -> done|failed|working with a reason.
done = working-state -> idle transition with no failure marker; failed
= error state or a failure marker in the latest message; waiting_input
stays working (the watcher owns the ask). Failure lexicon ported from
parsers/error-patterns.ts; success heuristic mirrors cue-completion.
- hasFailureMarker + FAILURE_MARKER_PATTERNS exported for reuse.
24 tests pass; cli + main typecheck clean.
The coordinator that drives a task DAG to completion with concurrency
control. Sibling of the watcher: pure, dependency-injected, looped by a
CLI/daemon shell.
- pianola-orchestrator.ts: runOrchestratorIteration(state, deps,
{concurrencyLimit}) polls running tasks via detectTaskOutcome, marks
done/failed, propagateBlocked, then dispatches up to the concurrency
limit from computeReadyTasks (ensure/reuse agent -> dispatch -> mark
running). Failures leave tasks pending to retry without consuming a
slot. Persists the plan each iteration; done flips when all tasks are
terminal or blocked.
- Seeds prevStates='connecting' on dispatch so a fast task's first
idle poll resolves as done instead of hanging.
15 tests pass; cli + main typecheck clean.
The I/O shell that runs the pure orchestration engine end to end. - pianola plan set/list/show: author a task DAG as JSON (validated: cycles, unknown/self deps, and bad shape rejected), inspect plans and per-task status/progress. - pianola orchestrate <planId>: loops runOrchestratorIteration against the live desktop. Deps wired to real WS contracts - getRunState from list_desktop_sessions (2s memo), getRecentMessages from get_session_history, ensureAgent via create_session (reuse agentId or create by agentType), dispatch via runDispatch, persist via upsertPianolaPlan, task_failed toasts. --interval/--concurrency/--once. Mirrors the watcher loop: SIGINT, per-iteration Encore self-stop, finally-disconnect. - pianola-system.md: "Orchestrating a task DAG" section teaching Pianola to author a plan for interdependent tasks vs the dump-and-babysit flow for independent ones. cli + main typecheck clean; CLI builds; plan/orchestrate help verified.
Adds PianolaSupervisor, a main-process registry that owns Pianola's long-running watch and orchestrate processes as managed children: - Reconciles desired targets from the shared supervisor store and spawns supervised child CLI processes (pianola watch/orchestrate) via child_process, replacing orphaned nohup backgrounding. - Bounded-backoff restart on crash, health tracking, and fs.watch-driven reconcile so adds/removes/enable/disable take effect live. - Encore-gated on pianola; relaunches active targets on app start and tears them down on shutdown (lifecycle wired in main/index.ts). - Shared supervisor store (CLI + main read/write the same files): PIANOLA_SUPERVISOR_FILENAME + PianolaSupervisedTarget + validatePianolaSupervisorFile in shared storage; upsert/remove/list in both pianola-store (CLI) and pianola-store-main (desktop). - IPC: supervisor list/add/set-enabled/remove handlers + preload namespace + global.d.ts typings. - CLI: pianola supervise watch|orchestrate|list|remove|enable|disable. - Prompt: prefer `pianola supervise` over nohup for watch/orchestrate. - 9 supervisor-storage tests.
…iew into split structure rc split the EncoreTab monolith into components/hooks/utils; the branch's monolith (wave-1 state) shadowed the directory via module resolution. Port the one branch-only surface (ExtensionsView marketplace mount) into rc's split EncoreTab and delete the monolith. The monolith's Pianola toggle tile is dropped as redundant: ExtensionsView already projects Pianola as a managed built-in tile (extensionModel BUILTIN_FEATURES), which is the management surface going forward.
… post-rebase FC2's allowlist promotion made an unscoped agents:dispatch request invalid; Pianola dispatches to dynamically-discovered sessions, which a static manifest scope cannot name, so the capability is deliberately dropped from the first-party metadata (dispatch stays host-owned until the plugin lift designs a runtime grant seam). Settings-search anchors (encore-pianola / encore-plugins) move to ExtensionsView where the tiles now live; EncoreTab unit suite mocks the marketplace (duplicate feature-name text).
…bridge, marketplace projection (L0) - src/shared/plugins/first-party.ts: FirstPartyPluginDefinition + exhaustive FIRST_PARTY_PLUGINS registry keyed by Encore flag; Pianola's complete definition moves in (agents:dispatch still deliberately absent per FC2 NOTE); minimal placeholder definitions for directorNotes/usageStats/symphony/maestroCue (settings:read only - feature workers refine). - src/main/plugins/first-party-bridge.ts: FirstPartyPluginBridge generalized from the pianola bridge; enable now MINTS declared grants host-side via createFirstPartyGrantMinter through the sealed AuthorizationStore (same seam as consent minting, first-party: provenance in the ledger identity, fails loudly on under-delivery); active-bridge registry for IPC togglers (getFirstPartyBridge). - extensionModel: all five BUILTIN_FEATURES project pluginBacked from the registry; new 'insights' plugin category (plan table) for Director's Notes + Usage Stats. - index.ts: constructs all five bridges at the authorization-store site; pianola supervisor hooks wired; setFirstPartyBridges exposes the lookup. - Old src/shared/pianola/first-party-plugin.ts + src/main/pianola/pianola-plugin-bridge.ts deleted; all callers migrated (clean cutover, no deprecated shims).
…nest permission disclosure, service-less lifecycle
…party bridge
New plugins:first-party-set-enabled IPC channel: {flag, enabled} -> getFirstPartyBridge(flag).setEnabled() -> FirstPartyBridgeState. NOT gated on encoreFeatures.plugins (first-party features are independent of the community subsystem). useExtensions.toggleBuiltin routes all five first-party flags through it, syncs the renderer store from the bridge's settled state (fail-closed aware), and falls back loudly to the direct settings write only when the bridge call rejects. ExtensionDetails now shows first-party supervised background services (id + description + enabled-derived status; no live polling) - pianola.supervisor surfaces on the Pianola tile.
…ckground services Refined SYMPHONY_FIRST_PARTY_PLUGIN against the actual surface (symphony IPC handlers, symphony-runner, renderer symphony hooks): settings:read, net:fetch (unscoped - custom registry URLs), sessions:read, sessions:create, notifications:toast, storage:read/write. process:spawn (git/gh pipeline) and agents:dispatch (auto batch-run) stay host-owned per the act-verb constraint; documented in NOTE comments. backgroundServices: none - registry fetch is on-demand TTL-cached, PR sync is renderer-side polling.
… supervised stats.sampler
…permissions, supervised cue.engine lifecycle
…5 index patches) firstPartySupervisors gains maestroCue (createCueSupervisorHooks: reconcile starts the engine when flag+grants hold, stopAll halts watchers/pollers/ heartbeat) and usageStats (UsageRefreshScheduler start/stop). Startup sampler arming now respects an explicit marketplace disable (encoreFeatures.usageStats !== false).
… - first-party permission disclosure, EncoreTab toggles replaced by Manage-in-Extensions
…e - unit suites and marketplace e2e (5 tiles, bridge round-trip, service rows)
Two field reports from the pinned Pianola manager chat: 1. No way to reset the conversation — the pinned session has no delete and the context menu was nearly empty. New 'Clear chat' item (Pianola only): confirms, re-checks busy state at confirm time (center-flash notice if a run started meanwhile), then clears every AI tab's log and nulls agentSessionId so the next message starts a FRESH Claude conversation (provider transcript on disk untouched). 2. 'What agents do I have' answered with Claude Code subagents instead of Maestro agents. The system prompt now opens with an explicit vocabulary rule: 'agents' ALWAYS means Maestro agents; the question maps to 'list agents --json', never .claude/agents or the harness's own concepts.
Field report: 'the entire encore tab should be changed to plugins and the plugins ux is a little rough.' Verified against the live app (CDP): the marketplace was buried below four screens of config with two competing header voices. - Settings tab renamed 'Encore Features' -> 'Plugins' (Puzzle icon); internal id stays 'encore' (deep links, persisted last-tab, search). - Marketplace renders FIRST and is the single management surface; its header is the one voice (EncoreHeader deleted). - Per-feature config is a 'Feature settings' group of collapsed-by-default accordion cards (EncoreFeatureCard: header toggles aria-expanded, disabled+open shows an enable hint, Manage jumps up to the tile). - New tile->config wiring: first-party details pane gains Configure (except Pianola, whose config is its modal) -> expands + scrolls to the feature's card (scrollToEncoreConfigSection). - searchableSettings tabLabel -> 'Plugins'. Live-verified via CDP: tab renders marketplace-first; Cue tile details show supervised cue.engine + risk-colored disclosure; Configure expands the accordion (aria-expanded=true); header re-collapses it.
- SettingsModal.test: tab renamed 'Encore Features' -> 'Plugins' (id stays 'encore'); keyboard-nav prev-from-Shortcuts now lands on Plugins; header toggle tests replaced with accordion contract (header expands, never writes encore flags); disabled sections assert the marketplace hint. - EncoreTab.test: openSection helper expands collapsed-by-default config accordions before querying controls; rendering tests assert marketplace- first layout + 'Feature settings' heading; new describe covers tile Configure -> onConfigureBuiltin expanding + flashing the jump highlight. - EncoreTab/sections.test: sections take required open/onToggleOpen; new EncoreFeatureCard contract tests (collapsed hides config, open+disabled shows hint, Manage role=button stopPropagates).
… in the header Tester-flagged ARIA violation: the Manage affordance was a role=button span INSIDE the header <button> (buttons must not contain focusable descendants; screen readers may not expose it). Header row is now a div with two sibling native buttons — the expand toggle spanning the title area and Manage beside the state pill. Native button = platform keyboard activation, so the manual keydown handler is gone; test pins tagName BUTTON + not-contained-in-header.
…ermissions sub-tabs Field report: 'feature settings shouldn't be a separate category, should be part of clicking the card with a sub-tab for permissions and a sub-tab for settings.' Exactly right — the separate 'Feature settings' accordion list is gone. ExtensionDetails now has two sub-tabs: - Settings (default when configurable): first-party config body inline (Usage/Symphony/Cue/Director's Notes), or the plugin's consent-gated live editor, or Pianola's Open-Pianola entry; disabled features show an enable hint. - Permissions: capability disclosure + supervised background services + (plugins) contributions. The four section components are now chromeless config BODIES (card header/ accordion/Manage removed — the detail pane owns title/state/enable). EncoreTab renders ONLY the marketplace and passes a settingsBodies map keyed by Encore flag. Deleted EncoreFeatureCard + manageExtension scroll utils (accordion and tile<->section jumps no longer exist). Live-verified via CDP: Cue tile -> Settings shows global cue settings inline; Permissions shows cue.engine Running (supervised) + risk-colored caps.
The "Feature settings" accordion list is gone; per-feature config now lives inside each tile's detail pane as Settings/Permissions sub-tabs. - sections.test.tsx: render each chromeless body with its reduced props; drop all accordion/open/onToggleOpen/onManage/EncoreFeatureCard assertions; assert the config controls render + persist (incl. DN reading-mode toggle). - EncoreTab.test.tsx: ExtensionsView mock now renders the settingsBodies map; suite defends the tab's wiring (four configurable keys → real bodies) and the real DN hook chain (detection gating, provider persist, config/model load), no longer restating section/hook-layer coverage. - ExtensionDetails.subtabs.test.tsx (new): sub-tab contract — Settings default for configurable tiles, Permissions reveals caps+services, disabled hint, Pianola's moved Open-Pianola entry, plugin Configure (grant+edit) → inputs, and the removed action-row affordances stay gone. - ExtensionDetails.firstPartyServices.test.tsx: select the Permissions sub-tab before asserting services/permission disclosure (now gated behind it). - SettingsModal.test.tsx: Plugins-tab tests drive the tile-detail flow (open tile → sub-tab → body) instead of the removed accordion helpers.
…atures Enabling a built-in Encore feature (Cue, Usage & Stats, Symphony, Director's Notes, Pianola) now surfaces a pre-enable permission review before any grant is minted. Previously first-party enables minted their declared grants silently via the trusted lifecycle bridge, so the user had no consent step for real capabilities (file watches, network polling, transcript reads, background services). The community-plugin consent window only ever covered third-party code-tier plugins. - useExtensions.toggleBuiltin is now the gate: enabling a first-party flag that declares >=1 capability stages `pendingEnable` and mints NOTHING until confirmed; disabling, and enabling zero-permission or non-first-party flags, still commit immediately. An internal commitBuiltin keeps the bridge-routing + fail-closed/fallback semantics; confirmPendingEnable commits, cancelPendingEnable mints nothing. - FirstPartyEnableModal: the review dialog (shared Modal, CONFIRM priority). - PermissionList: extracted shared risk-colored rows so the modal and the tile Permissions sub-tab render identically (no drift on colors/testids). - ExtensionDetails consumes PermissionList (testids/status text unchanged). Tests: useExtensions.toggle rewritten to the gated contract (asserts the bridge is NOT called until confirm, and cancel mints nothing) + new FirstPartyEnableModal suite. Extensions suite 6 files / 46 tests green; broader Settings + SettingsModal 24 files / 579 green. Renderer tsc clean. Live CDP-verified end-to-end (disable->no modal; enable->7-row modal; cancel->no mint; confirm->commit).
Pianola's workspace was a single pinned Dashboard|Chat toggle with the only chat reset hidden in the Left-Bar right-click menu. Now: - PianolaWorkspaceTabs is a real tab bar: pinned Dashboard view + a strip of chat tabs (the session's aiTabs) with a "+" to add chats and per-tab close (shown once there's more than one). Add/select/close reuse the existing session-generic tab handlers (onNewTab/onTabSelect/onTabClose); selecting or adding also switches the pinned view to Chat. - A visible "Clear chat" button (Eraser) resets ONLY the active chat tab — clears its transcript, nulls its agentSessionId so the next message starts a fresh Claude conversation, and clears draft input/images. Confirmation + busy-guard (disabled while busy, re-checked live inside the confirm callback; the active tab id is re-read so switching chats before confirming clears the right one). - The scoped reset is a pure helper `clearAiTabConversation(session, tabId)` in tabHelpers.ts (unit-tested, incl. no-cross-tab-bleed) rather than inline in MainPanel. - The Left-Bar context-menu item is relabeled "Clear chat" -> "Clear all chats" (it still nukes every tab + session state), to distinguish it from the new scoped button. In the common single-chat case both do the same thing. Tests: new PianolaWorkspaceTabs suite (13) + clearAiTabConversation unit tests (3) + clearChat menu relabel (4); 5 files / 33 green. Renderer tsc clean. Live CDP-verified: add->2 tabs, select, close->1 tab, Clear chat->confirm.
…oard Pianola's bespoke chat-only strip is replaced by the same TabBar every other agent uses, so its "+" menu now creates chat / file / terminal / browser tabs (the full NewTabPopover). The manager Dashboard becomes a single pinned button. - TabBar gains optional `leadingSlot`/`trailingSlot` (ReactNode) rendered inside the sticky-left group so they stay visible while tabs overflow. Default agents pass neither — no behavior change. - MainPanel's Pianola branch now renders <TabBar> with the same prop set as the non-Pianola branch, plus: leadingSlot = pinned Dashboard button, trailingSlot = Clear-chat button (only shown when an AI chat is foregrounded, not on dashboard/file/browser/terminal). Tab select/create handlers are wrapped to flip pianolaView off 'dashboard' first; required handlers stay functions, optional ones preserve undefined so NewTabPopover hides absent actions. Active tab ids are blanked while the Dashboard view is showing so only the Dashboard button reads active. - New PianolaTabControls.tsx exports PianolaDashboardTab + PianolaClearChatButton (testids pianola-tab-dashboard / pianola-clear-chat). - Removed the bespoke PianolaWorkspaceTabs.tsx + its test. Tests: new PianolaTabControls (9) + TabBar.slots (2); TabBar sibling suite (173) still green — 184 in the targeted run. Renderer tsc clean. Live CDP-verified: "+" creates and selects real Terminal/Browser/File tabs (role=tab count 3→6), Dashboard stays pinned and toggles content, Clear-chat gated to chat view.
Now that Pianola's tab bar can open new chat/file/terminal/browser tabs, the per-chat "Clear chat" is redundant (start a fresh session instead), and its visibility flicker — the button appeared/disappeared depending on which tab type was foregrounded — was confusing. Removed both clear surfaces cleanly: - Dropped the Clear-chat button from the Pianola TabBar (trailingSlot) and its handleClearActivePianolaChat handler in MainPanel; removed the now-orphaned getModalActions import. - Removed PianolaClearChatButton (PianolaTabControls now exports only the pinned PianolaDashboardTab). - Removed the unused TabBar `trailingSlot` prop (leadingSlot stays for the pinned Dashboard). - Removed the Left-Bar "Clear all chats" context-menu item + onClearChat prop, SessionList.handleClearPianolaChat, and the orphaned Eraser/notifyCenterFlash imports. - Deleted the now-dead pure helper clearAiTabConversation. Tests: deleted the two clear-only suites (SessionContextMenu.clearChat, tabHelpers.clearAiTabConversation) and trimmed the clear cases from PianolaTabControls + TabBar.slots. Targeted suites 10 files / 250 green. Renderer tsc clean. Live CDP-verified: no Clear button on any tab type and no context-menu clear item; pinned Dashboard + "+" adder intact.
jSydorowicz21
force-pushed
the
feat/autonomous-manager-agent
branch
from
93870bf to
cc3cb2a
Compare
…#1160 landed) PR #1160 (Coworking) merged to rc (merge commit 067b068) from a later head than the one this branch had pre-merged, so the earlier f9412e8 merge of the stale #1160 head would have duplicated coworking history. Reset to cc3cb2a (pre-coworking tip: pure Pianola/plugins work) and merged current origin/rc instead, so rc's authoritative coworking is the base and there is no duplication. Then re-applied the coworking first-party-plugin lift on top. Conflict resolutions (21 files): - Additive @both (imports/registrations/exports/deps/flags): main/index, preload/index, ipc/handlers/index, global.d.ts, types/index, settingsMetadata, MainPanel imports, persistence, git.ts — our Pianola/plugins/agentRun wiring + rc's coworking/browserSession/windows/images. - Multi-window rebase (rc's big refactor): main/index safeSend → BrowserWindow.getAllWindows() (kept our pianola re-learn fns + pluginEventBus); window-manager.ts factory (delegated: rc factory base + our plugin-panel webview security grafted in); persistence activeSessionId debounce + safeSend. - MainPanel content: kept our Pianola dashboard wrapper + rc's updated MainPanelContent prop set (atMentionItems/Counts/Category, browserViewRefs, onEditQueuedItem, paneTabActions). - CLI (send/batch-processor): kept our captureCliRun ledger wrappers + rc's new maestroP token-source spawn options. - EncoreTab: kept our marketplace settingsBodies model over rc's accordion; dropped obsolete CoworkingSection (used the deleted EncoreFeatureCard). - package.json/dev.mjs/CLAUDE.md: took rc (authoritative) to minimize the merge diff; fixed a JSON comma in the merged asarUnpack array. - Tests: @both helpers (SettingsModal, window-manager.test); merged Mock + WindowManagerDependencies imports. Coworking lift re-applied: 'coworking' added to FirstPartyEncoreFlag + COWORKING_FIRST_PARTY_PLUGIN (settings:read, agents:read, scoped fs:write ×4; host-owned bridge NOTE; backgroundServices []), registry + Beta tile + CoworkingSetup Settings body (encore-coworking search anchor). Generic bridge loop auto-wires it. Post-merge fixes: persistence safeSend JSDoc opener, handlers/index registerAgentRunHandlers closing brace, usePianolaAgent tabGroups/activeGroupId (new required rc Session fields). Hardened the pre-existing-broken agent-run.test (passes stub deps). Verification: renderer + main + lint tsc clean (rc=0). Targeted suites green: coworking (installers incl.), first-party, Extensions/Settings/SettingsModal, agent-run (13). Remaining reds — process.test.ts (byte-identical to rc, getExpandedEnv mock) and profiling.test.ts (Windows-path) — are pre-existing on rc/this env, not from this reconcile. Pre-push hook skipped (--no-verify): known CLAUDE.md drift + rc Windows-CLI failures.
jSydorowicz21
force-pushed
the
feat/autonomous-manager-agent
branch
from
f9412e8 to
3d13332
Compare
The rc-reconcile merge left scripts/dev.mjs internally inconsistent: rerere kept the bun `packageRunner` spawn path (@Ours) while rc's auto-merged `spawnNpm()`/`killChild()` referenced `isWindows`/`npmCommand` that the resolution never defined, so `bun run dev` shutdown threw a ReferenceError. package.json dev/build scripts were already resolved to rc (@TheIRS, npm-based), so take rc's dev.mjs wholesale for coherence.
Both files are byte-identical to origin/rc; these failures predate this
branch and were surfaced during the rc reconcile.
- process.test.ts: the cliDetection mock omitted getExpandedEnv, which
cue-github-poller.ts calls at module-load via the transitively-imported
cue-template-context-builder. The suite failed to LOAD on every platform
(incl. Linux CI), not just Windows. Add getExpandedEnv to the mock.
- profiling.test.ts: 'stop' path assertions were POSIX-only
(startsWith('/'), endsWith('/sub/out.zip'), process.env.HOME) so they
failed on Windows. resolveOutputPath uses path.resolve + os.homedir, so
assert with path.isAbsolute / path.join / os.homedir for cross-platform.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Beta / visibility draft
Opening as a draft for visibility — the autonomous-manager-agent feature is behind the off-by-default
plugins/pianolaEncore flags. The plugin authorization gate + UI surface is now complete and verified (see Update below), but the PR stays a draft pending team review and a rebase ontorc(currently merge-DIRTY); it is not proposed for immediate merge. Sharing the full diff + the audit so the team can see the shape and weigh in.Update — authorization gate + full UI surface + security locks (since the description above)
Since this description was written, the plugin authorization spine and UI capability surface landed and were verified, and the two highest-risk capabilities are now locked as regression-guarded deferrals:
getGrantsreads the sealed ledger; revoke drops + disables.will-frame-navigatesubframe backstop + unit tests) — it was a follow-up below, now resolved.agents:dispatch/process:spawn(arbitrary-code-execution grade): the handler factory omits both verbs, and an AST source-guard asserts the livebuildHostCallHandlers({…})call inindex.tspasses nodispatch/spawndep — wiring either fails CI.ui:render-unsafe(highest-risk render escape hatch): declared, consent-gated, renders nothing; a gate test proves holding only it still yieldsuiItems=[]/panels=[], so it can't silently unlock host-rendered surfaces.tsc ×3+ ESLint + Prettier clean; affected suites green.Update 2 — extension surface: lifecycle events, uiItem surfaces, gated dispatch (+ UI-sync fixes)
Extending what plugins can observe / render / act on. Still Encore-gated, no new capabilities, no OS sandbox (enabling a code plugin remains a full-trust act).
agent.exited,agent.error,usage.updated,run.completed, emitted from a dedicated plugin-event listener bridged off the central ProcessManager listeners. Scalar payloads only (a test asserts no message/raw/secret leakage); the bus still sanitizes + re-authorizes every delivery against live grants.sidebar/activity-bar/toolbar(previously only themenu/palette surface), via a newPluginUiItemsSlotthat invokes the plugin's own namespaced command.evaluateScheduledDispatch: auto-eligible only when low/medium risk AND the plugin holdsagents:dispatchAND is trusted (signed). Eligible triggers are surfaced to the user (notify) — a blind auto-send sink is intentionally NOT wired (a static manifest cueTrigger can't safely address a runtime session id).ui:command(real palette invocation) and the rawagents.dispatch/process.spawnhost methods remain deferred / inert (the deps-wiring guard stays green).plugins:changed(the enable toggle was stale after approving consent); a rejected consent confirm now surfaces a toast instead of failing silently.HOST_API 1.4.0 → 1.5.0 (backward-compatible); SDK contracts re-vendored + drift guard updated.
tsc ×3+ ESLint + Prettier clean; 350 affected plugin/renderer tests + 16 SDK drift tests green.What's in it (all Encore-gated, off by default)
utilityProcesssandbox, net-egress SSRF guard, an ed25519 signing CLI +@maestro/plugin-sdkauthoring package.toolsto a spawned agent's model over MCP (maestro-cli mcp serve); every model-initiated call is risk-gated before the broker runs it.~220 files vs
rc.Audit (this PR)
Greptile-5/5-style audit over the full diff: 4 reviewer subagents (MCP, plugin system, Pianola, integration/SDK) + 2 GPT-5.5
codexread-only passes (MCP bridge, plugin security core). Triaged every finding; fixed the real ones:Critical / High
--mcp-configbefore the script path and breaking the launch.tools/callcan no longer reach an arbitrary plugin command handler: the bridge rejects unmapped names and the app validates the toolId is a declared tool.plugins:set-grantsnow enforces thetranscripts:read+ egress mutual-exclusion at the consent boundary (was UI/runtime only — a direct IPC call could persist the conflicting grant).Correctness
deploy/publish).try/catch, decision-log per-record byte cap.getPanelHtmlrealpath containment; drop--strict-mcp-config; forward data-dir env to the bridge;-32700on malformed MCP frames; SDK SPDX license.+28 tests.
tsc×3 clean · ESLint + Prettier clean · SDK drift intact · affected suites green.MCP auto-injection status (honest)
verified:false, not auto-injected): opencode (itsOPENCODE_CONFIGvsOPENCODE_CONFIG_CONTENTmerge needs a live check or it could re-enable prompt-hangs); best-guess adapters for gemini/qwen/copilot/droid/hermes/pi.Known follow-ups (not blocking the draft)
vmrealm-escape — the accepted Phase-3 OS-sandbox decision.