@adhdev/daemon-core 0.9.82-rc.35 → 0.9.82-rc.350

package/dist/cli-adapters/resolve-executable.d.ts

@@ -0,0 +1,14 @@
+/**
+ * Resolve a launch command to an absolute executable path on Windows.
+ *
+ * node-pty's ConPTY backend resolves a bare/relative command against the
+ * *calling process's* `Path` env var and — critically — does NOT apply PATHEXT.
+ * So a provider command like `claude` never matches `claude.exe` and the native
+ * layer throws `File not found:` (empty), which crashes the daemon. We resolve
+ * it to an absolute `.exe` here (in the daemon process, which has the full PATH)
+ * before the command ever reaches node-pty.
+ *
+ * No-op on non-Windows and when the command is already an existing absolute path
+ * or cannot be resolved (caller keeps the original behaviour).
+ */
+export declare function resolveWin32Executable(command: string): string;

package/dist/cli-adapters/terminal-backends/ghostty-vt-backend.d.ts

@@ -1,13 +1,16 @@
-import type { TerminalViewportBackend, TerminalViewportBackendOptions, TerminalViewportBackendPreference } from './types.js';
-export declare function resolveTerminalBackendPreference(): TerminalViewportBackendPreference;
-export declare function isGhosttyVtBackendAvailable(): boolean;
+import type { TerminalViewportBackend, TerminalViewportBackendOptions } from './types.js';
 export declare class GhosttyVtTerminalBackend implements TerminalViewportBackend {
     readonly kind: "ghostty-vt";
     private terminal;
+    private rows;
+    private disposed;
     constructor(options: TerminalViewportBackendOptions);
     resize(rows: number, cols: number): void;
     write(data: string): void;
+    private formatLines;
+    private static trimBlankEnds;
     getText(): string;
+    getTextWithScrollback(): string;
     getCursorPosition(): {
         col: number;
         row: number;

package/dist/cli-adapters/terminal-backends/types.d.ts

@@ -1,5 +1,4 @@
-export type TerminalViewportBackendKind = 'xterm' | 'ghostty-vt';
-export type TerminalViewportBackendPreference = TerminalViewportBackendKind | 'auto';
+export type TerminalViewportBackendKind = 'ghostty-vt';
 export type TerminalViewportBackendOptions = {
     rows: number;
     cols: number;
@@ -10,6 +9,15 @@ export interface TerminalViewportBackend {
     resize(rows: number, cols: number): void;
     write(data: string): void;
     getText(): string;
+    /**
+     * Like getText() but includes scrollback history (the lines that have
+     * scrolled above the visible viewport). Used by content-pattern matching
+     * (e.g. approval/modal button extraction) that must stay correct when a
+     * tall prompt — a big diff or long explanation — pushes part of the
+     * prompt box above the viewport. NOT for cursor-relative / stable_ms
+     * conditions, whose row indices are viewport-relative.
+     */
+    getTextWithScrollback(): string;
     getCursorPosition(): {
         col: number;
         row: number;

package/dist/cli-adapters/terminal-screen.d.ts

@@ -1,29 +1,22 @@
 /**
- * PTY screen snapshot abstraction.
- *
- * Terminal viewport backend selection.
- *
- * Runtime preference is backend-agnostic:
- * - prefer ghostty-vt when available (or when explicitly requested)
- * - fall back to xterm when ghostty-vt is unavailable
+ * PTY screen snapshot abstraction — ghostty-vt backend.
  */
-import type { TerminalViewportBackendKind, TerminalViewportBackendPreference } from './terminal-backends/types.js';
+import type { TerminalViewportBackendKind } from './terminal-backends/types.js';
 export declare function getTerminalBackendRuntimeStatus(): {
     backend: TerminalViewportBackendKind;
-    preference: TerminalViewportBackendPreference;
-    ghosttyAvailable: boolean;
 };
 export declare class TerminalScreen {
     readonly backendKind: TerminalViewportBackendKind;
     private rows;
     private cols;
-    private readonly preference;
     private terminal;
     constructor(rows?: number, cols?: number);
     reset(rows?: number, cols?: number): void;
     resize(rows: number, cols: number): void;
     write(data: string): void;
     getText(): string;
+    /** Full buffer including scrollback history (see backend doc). */
+    getTextWithScrollback(): string;
     getCursorPosition(): {
         col: number;
         row: number;

package/dist/commands/cli-manager.d.ts

@@ -6,7 +6,7 @@
  */
 import type { ProviderInstanceManager } from '../providers/provider-instance-manager.js';
 import { ProviderLoader } from '../providers/provider-loader.js';
-import { type ProviderModule, type ProviderResumeCapability } from '../providers/contracts.js';
+import { type MeshCoordinatorDelegatedWorkerIsolation, type ProviderModule, type ProviderResumeCapability } from '../providers/contracts.js';
 import type { CliAdapter } from '../cli-adapter-types.js';
 import type { PtyTransportFactory } from '../cli-adapters/pty-transport.js';
 import type { SessionRegistry } from '../sessions/registry.js';
@@ -68,6 +68,7 @@ export interface CoordinatorDelegatedCliLaunchOptionsInput {
     workspace: string;
     cliArgs?: string[];
     env?: Record<string, string>;
+    isolation?: MeshCoordinatorDelegatedWorkerIsolation;
 }
 export interface CoordinatorDelegatedCliLaunchOptions {
     cliArgs: string[];

package/dist/commands/handler.d.ts

@@ -104,7 +104,117 @@ export declare class DaemonCommandHandler implements CommandHelpers {
     setAgentStreamManager(manager: DaemonAgentStreamManager): void;
     handle(cmd: string, args: any): Promise<CommandResult>;
     private dispatch;
+    /**
+     * Reload providers from disk. Does NOT pull from the registry — the user
+     * controls installs explicitly via install_provider_manifest. To upgrade
+     * an installed provider, call install_provider_manifest again with the
+     * desired version (or with no version to pick up the latest from
+     * registry), or use check_provider_updates to see what is out of date.
+     */
     private handleRefreshScripts;
+    /**
+     * Return per-provider availability so the dashboard's provider catalog
+     * can show "Installed" badges. Reuses the existing detection state from
+     * ProviderLoader.getMachineProviderStatus() — no probing is triggered.
+     */
+    private handleListProviderAvailability;
+    /**
+     * Compute the *upstream cache root*. install_provider_manifest writes
+     * official-registry manifests here so the daemon's standard upstream
+     * layer picks them up — no special handling needed at load time, and
+     * the manifests inherit the official-trust badge instead of the
+     * untrusted-external one.
+     *
+     * Path matches ProviderLoader.upstreamDir but we recompute it from
+     * homedir() so this method stays usable in dev where userDir can
+     * point at a sibling git checkout.
+     */
+    private getUpstreamInstallRoot;
+    /**
+     * Download a single provider manifest from the registry and write it to
+     * ~/.adhdev/providers/.upstream/{category}/{type}/provider.json.
+     *
+     * Used by standalone onboarding to seed the upstream cache with the
+     * default provider set on first launch. Verifies SHA-256 checksum
+     * against the registry meta before persisting. Refuses to write
+     * outside the upstream root.
+     *
+     * Args: { type: string, category?: string, version?: string }
+     * If category/version are omitted, looks up the latest from the registry.
+     */
+    private handleInstallProviderManifest;
+    /**
+     * If `manifest.source = { type:'github', repo, ref, subdir? }` is set,
+     * walk each script directory the manifest references and download every
+     * file from the public GitHub raw endpoint. Returns a small summary so
+     * the caller can report what was fetched.
+     *
+     * Best-effort: failures don't reject the install — the manifest itself is
+     * usable for declarative-only providers, and the user still gets a clear
+     * error string back if a needed script is missing.
+     */
+    private fetchProviderSources;
+    /**
+     * Remove a provider manifest from the upstream cache root
+     * (~/.adhdev/providers/.upstream/{category}/{type}/). Refuses to touch
+     * anything outside that root. Used by onboarding to opt out of a
+     * provider the user doesn't want; the dashboard no longer exposes a
+     * per-provider uninstall button (external sources are removed as a
+     * whole via remove_provider_source).
+     */
+    private handleUninstallProviderManifest;
+    /**
+     * Return everything currently installed in the upstream cache with its
+     * version. This is the "what does this daemon have" answer used both by
+     * the UI and by the update checker.
+     */
+    private handleListInstalledProviders;
+    /**
+     * For each installed provider, ask the registry for its current latest
+     * version and report whether an update is available. The user can then
+     * call install_provider_manifest to upgrade (it overwrites the file).
+     *
+     * Returns { providers: [{ type, category, installedVersion, latestVersion,
+     *   updateAvailable, error? }] }
+     */
+    private handleCheckProviderUpdates;
+    /**
+     * Register a new external provider source. The daemon clones the repo
+     * to ~/.adhdev/external/<name>/, walks it once to detect provided
+     * types, and surfaces any conflicts with already-installed types so
+     * the dashboard can ask the user how to resolve them.
+     *
+     * Args: { url: string, ref?: string, name?: string }
+     *   - url: https://, git@, or any git-cloneable URL
+     *   - ref: branch/tag/commit (default "main")
+     *   - name: short identifier (default derived from URL)
+     *
+     * Returns: { source, providers, conflicts }
+     *   - conflicts: list of types this new source provides that another
+     *     source already exposes. UI uses this to prompt for active-source
+     *     selection before the load takes effect.
+     */
+    private handleAddProviderSource;
+    /**
+     * Remove a registered external source. Deletes the clone directory and
+     * any active-source entry pointing to it.
+     *
+     * Args: { name: string }
+     */
+    private handleRemoveProviderSource;
+    /**
+     * List registered external sources + each source's currently installed
+     * providers + the active selection for any conflicting types. Used by
+     * the dashboard's "Sources" tab.
+     */
+    private handleListProviderSources;
+    /**
+     * Pick which source's copy of a conflicting provider type is active.
+     * Other sources' copies stay on disk but the loader ignores them.
+     *
+     * Args: { type: string, sourceName: string }
+     */
+    private handleSetActiveProviderSource;
     private proxyDevServerPost;
     private proxyDevServerGet;
     private proxyDevServerScaffold;

package/dist/commands/mesh-coordinator.d.ts

@@ -1,4 +1,4 @@
-import type { ProviderModule, MeshCoordinatorMcpConfigFormat } from '../providers/contracts.js';
+import type { MeshCoordinatorMcpConfigFormat, MeshCoordinatorSystemPromptInjection, ProviderModule } from '../providers/contracts.js';
 export interface MeshCoordinatorMcpServerLaunch {
     command: string;
     args: string[];
@@ -25,6 +25,7 @@ export type MeshCoordinatorSetup = {
     command: string;
     requiresRestart: boolean;
     instructions: string;
+    mcpServer: MeshCoordinatorMcpServerLaunch;
 } | {
     kind: 'unsupported';
     reason: string;
@@ -42,3 +43,86 @@ export interface ResolveMeshCoordinatorSetupOptions {
 }
 export declare function createHermesManualMeshCoordinatorSetup(meshId: string, workspace: string): MeshCoordinatorSetup;
 export declare function resolveMeshCoordinatorSetup(options: ResolveMeshCoordinatorSetupOptions): MeshCoordinatorSetup;
+/**
+ * Apply a provider's declared system-prompt injection rule, mutating `cliArgs`
+ * and `launchEnv` in place and writing any required workspace context file.
+ *
+ * Replaces the previous hard-coded `if (cliType === 'claude-cli') ... else if
+ * (cliType === 'hermes-cli') ...` branches in router.ts. Adding a new CLI is
+ * now provider.v1.json data, not a router edit.
+ *
+ * Failures are non-fatal: log and continue with whatever was applied so the
+ * coordinator session still launches, just without the prompt for that
+ * provider. A missing/unknown rule means "skip injection" — safe by default
+ * (the previous fallback unconditionally pushed --append-system-prompt onto
+ * every non-Claude CLI, which crashed agy on launch).
+ */
+export interface CoordinatorInjectionEffect {
+    /** Absolute path the daemon wrote a wrapper-blocked file to. Only set for
+     *  context_file injection. R48 schedules a strip after launch so workers
+     *  don't see the wrapper on disk; R47's unregister cleanup uses it as a
+     *  fallback if the timer never fires (process crash, etc). */
+    contextFilePath?: string;
+}
+export declare function applyMeshCoordinatorSystemPromptInjection(systemPrompt: string, injection: MeshCoordinatorSystemPromptInjection | undefined, ctx: {
+    cliArgs: string[];
+    launchEnv: Record<string, string>;
+    workspace: string;
+    cliType: string;
+}): CoordinatorInjectionEffect;
+/**
+ * Strip the daemon's wrapper block from a context_file we previously wrote.
+ *
+ * Used in two places:
+ *   1. R48 inject-then-remove: ~5s after spawn, after agy/gemini have read
+ *      the file into their in-memory system-prompt cache. Removing it from
+ *      disk at that point doesn't affect the running coordinator but keeps
+ *      worker sessions (or fresh non-coordinator launches) in the same
+ *      workspace from picking up our wrapper.
+ *   2. R47 unregister fallback: if the timer never fires (process crash,
+ *      kill -9), coordinator-registry.unregisterMeshCoordinator runs the
+ *      same logic when its entry is dropped.
+ *
+ * Idempotent: missing file is fine, missing sentinels are fine, returns
+ * silently. Leaves user-authored content outside the sentinels intact.
+ * Deletes the file outright if our wrapper was the only content.
+ */
+export declare function stripCoordinatorWrapperFile(filePath: string): void;
+export interface PtyExecResult {
+    exitCode: number | null;
+    signal: number | null;
+    output: string;
+    timedOut: boolean;
+}
+export interface MeshCoordinatorRegistrationStep {
+    command: string;
+    args: string[];
+    required: boolean;
+    label: 'remove_existing' | 'register';
+}
+/**
+ * Codex rejects `mcp add` when a server with the same name already exists.
+ * Replace that entry before registering so transport/mesh changes do not leave
+ * a fresh coordinator attached to stale MCP launch arguments.
+ */
+export declare function buildMeshCoordinatorRegistrationPlan(cliType: string, serverName: string, registrationCommand: string): MeshCoordinatorRegistrationStep[];
+/**
+ * Run a one-shot CLI command under a real PTY and collect its output.
+ *
+ * Some provider mcp-registration commands (`agy mcp add`, future bubbletea
+ * TUIs) refuse to run without `/dev/tty`. Daemon-side `execFileSync` runs
+ * pipe-only, so those commands fail with errors like
+ *   `bubbletea: error opening TTY: open /dev/tty: device not configured`
+ * and silently skip the registration, leaving the launched session
+ * without the adhdev-mesh MCP tools — which is exactly what we saw with
+ * agy coordinators.
+ *
+ * Wrapping the registration through node-pty gives the child a real PTY,
+ * so the bubbletea check passes. We close stdin immediately and just
+ * collect stdout until the process exits or the timeout fires.
+ */
+export declare function execUnderPty(command: string, args: string[], options?: {
+    cwd?: string;
+    env?: Record<string, string>;
+    timeoutMs?: number;
+}): Promise<PtyExecResult>;