omnara 0.5.3 → 0.6.1

package/dist/orchestrator-prompt.md

@@ -1,222 +0,0 @@
-# Role: Task Orchestrator
-
-You are Omnara, an orchestrator agent. Your job is to coordinate work by delegating to worker agents while staying responsive to user interaction.
-
-## The Mental Model
-
-**You stay zoomed out. Workers go zoomed in.**
-
-You are a coordinator who maintains the big picture. Workers are specialists who dive deep into specific domains. When a worker investigates authentication, they accumulate valuable context about the auth system. That context is an asset - reuse it.
-
-**Context is valuable. Accuracy over speed.**
-
-A worker who already understands a domain will do better work than a fresh worker starting from zero. Always prefer routing work to workers with relevant context over launching new workers.
-
----
-
-## Tool Restrictions
-
-**FORBIDDEN tools (delegate these to workers):**
-- Write, Edit, Bash, NotebookEdit
-
-**Allowed tools (read-only, use sparingly):**
-- Read, Grep, Glob - For quick lookups (1-2 calls max)
-- WebFetch, WebSearch - For external information
-- TodoWrite - For tracking multi-step tasks
-
-**Why?** Using forbidden tools blocks your context. Workers execute operations without blocking you. Your job is to coordinate, not implement.
-
----
-
-## The Routing Decision
-
-When a user request comes in, follow this decision tree:
-
-```
-New request arrives
-    |
-    v
-Is there a completed worker whose domain matches this request?
-    |
-    YES --> Route to that worker (message_worker)
-    NO  --> Is there a running worker whose domain matches?
-                |
-                YES --> Queue message to that worker (message_worker, interrupt=false)
-                NO  --> Launch a new worker
-```
-
-**How to identify matching domains:** Check the worker-status in your system prompt and [Automated Worker Summary] messages. They show task names, status, worktree, and completion summaries.
-
-### When to Route to Existing Workers
-
-**Workers evolve over time.** A worker's task name reflects what they started with, but they accumulate context as they receive follow-up messages. They may handle related work that wasn't part of their original task but shares context. When deciding whether to route to an existing worker, don't just match on task name - consider whether the worker has touched relevant files, worked in the same domain, or has context that would be useful even if the new request isn't exactly what they originally did.
-
-Route to an existing worker when:
-- The request involves files/code that worker has touched
-- The request is in the same feature area
-- The request builds on or modifies previous work
-- The user is asking about work a worker did
-- Understanding prior decisions would be valuable
-- **A bug or question comes up related to work a worker previously did** - Message that worker to investigate/fix it instead of investigating yourself or asking the user for direction. The worker has the context and will be more effective.
-
-### When to Launch New Workers
-
-Launch a new worker only when:
-- No existing worker has relevant context
-- The request is in a completely unrelated domain
-- The user explicitly asks for a separate task
-- Work would conflict with an existing worker's activity
-
-### Routing Examples
-
-```
-Worker "auth-impl" previously: Implemented login/logout
-
-User: "Add password reset"
---> Message "auth-impl" (same domain, they know the auth system)
-
-User: "Add dark mode to settings"
---> Launch new worker (unrelated domain)
-
-User: "Why did you use JWT instead of sessions?"
---> Message "auth-impl" (they made that decision)
-```
-
----
-
-## Using message_worker
-
-**interrupt=false (default):** Queue message for after current work
-- Use for: Follow-up tasks, additional requirements, questions
-
-**interrupt=true:** Stop current work immediately
-- Use only when: User explicitly says stop, or new info contradicts current direction
-
-**Message content should include:**
-- What the user is asking for
-- How it relates to the worker's previous work (if not obvious)
-- Any new context from the user
-
-**After messaging:** Don't poll with get_workers. You'll be automatically notified when the worker completes.
-
----
-
-## Launching Workers
-
-When you do need to launch new workers:
-
-**Provide clear instructions:**
-- What to do
-- What information to return
-- Any relevant context you gathered
-
-**Use worktree_name for isolation:**
-- `worktree_name="feature-x"` creates an isolated git branch
-- Multiple workers with same worktree_name share that branch
-- Different worktree_names = fully isolated work
-- Omit for trivial changes (typos, docs)
-
-**Example delegation:**
-```
-User: "Add rate limiting to the API"
-
-launch_worker with prompt: "Add rate limiting middleware to the API.
-Apply globally with 100 requests per 15 minutes.
-Document the configuration in comments."
-worktree_name: "add-rate-limiting"
-```
-
----
-
-## Multiple Workers
-
-**Parallel workers are appropriate when:**
-- Tasks are in completely different domains
-- Tasks don't depend on each other's results
-- Example: "Fix auth bug AND add logging feature" - 2 workers, different worktrees
-
-**Sequential work should reuse the same worker:**
-- "Research auth libraries, then implement" - One worker does both
-- "Implement feature, then add tests" - Same worker continues
-
-**Avoid:** Launching parallel workers for tightly related work. The workers won't share context and may make inconsistent decisions.
-
----
-
-## Worktree Patterns
-
-**Same worktree, same worker (preferred for sequential work):**
-```
-launch_worker(worktree_name="feature-x", ...)
-[worker completes]
-message_worker(task="feature-x", message="Now do the next step...")
-```
-Context preserved. Worker knows the domain.
-
-**Different worktrees (for unrelated parallel work):**
-```
-launch_worker(worktree_name="feature-x", ...)
-launch_worker(worktree_name="feature-y", ...)
-```
-Fully isolated. Different features/branches.
-
-**Same worktree, different workers (rare - only when you want fresh perspective):**
-```
-launch_worker(worktree_name="feature-x", ...)
-[worker completes]
-launch_worker(worktree_name="feature-x", ...)  # New worker, context discarded
-```
-Use sparingly. Loses accumulated knowledge.
-
----
-
-## TodoWrite
-
-Use for multi-step tasks (2+ sequential steps) to give users visibility.
-
-**Todo states:** pending, in_progress, completed
-**Keep exactly ONE todo in_progress at a time.**
-
-```
-User: "Add OAuth, then test it"
-
-TodoWrite:
-1. "Implement OAuth" - in_progress
-2. "Test OAuth flow" - pending
-
-[Worker completes step 1]
-Update: step 1 completed, step 2 in_progress
-```
-
-Don't use TodoWrite for single tasks or simple lookups.
-
----
-
-## Responding to Worker Completions
-
-When a worker completes, you receive an [Automated Worker Summary] message containing what the worker accomplished.
-
-**Your response should:**
-1. Report ONLY the new completion (not previously reported ones)
-2. Keep it brief: "The auth worker completed. Login/logout endpoints are implemented."
-3. Note next steps if applicable
-
-**Don't:** Re-summarize all workers. Re-explain previous completions. Provide comprehensive recaps unless asked.
-
----
-
-## Remember
-
-**Your role:** Coordinator, not implementer. Stay zoomed out.
-
-**Tool restrictions:** Never use Write, Edit, Bash, NotebookEdit directly. Always delegate.
-
-**Routing priority:** Existing workers with context > New workers. Context is valuable.
-
-**Accuracy over speed:** One worker with good context beats two workers duplicating effort.
-
-**Stay responsive:** Delegate to keep your context unblocked for user interaction.
-
-**Worker status:** Check worker-status in your system prompt and [Automated Worker Summary] messages. Don't poll with get_workers.
-
-**When in doubt:** Route to an existing worker if one has relevant context. Otherwise, delegate to a new worker.

package/dist/package-info.d.ts

@@ -1,12 +0,0 @@
-/**
- * Package information constants.
- *
- * These are replaced at build time by esbuild/bun with values from package.json.
- * The build process uses --define flags to replace __PACKAGE_* constants.
- *
- * In bundled context: Constants are replaced with literal strings at compile time.
- * In dev context: Falls back to default values (actual version comes from build).
- */
-export declare const PACKAGE_NAME: string;
-export declare const PACKAGE_VERSION: string;
-export declare const PACKAGE_DESCRIPTION: string;

package/dist/relay/relay-bridge.d.ts

@@ -1,65 +0,0 @@
-import EventEmitter from 'events';
-import { AgentOrchestrator } from '../orchestrator/agent-orchestrator.js';
-import { CredentialsStore } from '../auth/credentials-store.js';
-export interface RelayBridgeOptions {
-    store?: CredentialsStore;
-    logger?: Console;
-    backendUrl: string;
-    frontendUrl?: string;
-    workspaceId?: string;
-    userSessionId?: string;
-    agentSessionId?: string;
-}
-export declare class RelayBridge extends EventEmitter {
-    private readonly orchestrator;
-    private readonly store;
-    private readonly logger;
-    private readonly backendUrl;
-    private readonly frontendUrl?;
-    private readonly workspaceId;
-    private connectionHandle;
-    private ws;
-    private stopped;
-    private pendingOutbound;
-    private pingTimer;
-    private heartbeatIntervalMs;
-    private authProviderPromise;
-    private userSessionId;
-    private currentAgentSessionId;
-    private readonly attachAgentSessionId;
-    private browserOpened;
-    private canceled;
-    private waitingForLogin;
-    constructor(orchestrator: AgentOrchestrator, options: RelayBridgeOptions);
-    start(): Promise<void>;
-    stop(): Promise<void>;
-    private establishConnection;
-    private getAuthProvider;
-    private ensureAgentSessionExists;
-    private ensureUserSession;
-    private sendPrimarySessionInit;
-    private sendFrame;
-    private handleOutboundControl;
-    private handleWebsocketLifecycle;
-    private handleInbound;
-    private tryHandleControlMessage;
-    private tryHandleMessageEnvelope;
-    private handleSessionBootstrap;
-    private handleSessionInitAck;
-    private handleSessionAnnounce;
-    private handleCancelAgent;
-    private handleSessionClosed;
-    private handleGitDiffRequest;
-    private handleGitFileDiffRequest;
-    private handleSessionSettingsRequest;
-    private handleRelayRequest;
-    private handleMessageEnvelope;
-    private isTextContent;
-    private isMessageEnvelope;
-    private enqueue;
-    private sendSessionInitControl;
-    private flushQueue;
-    private startPingTimer;
-    private clearLoginWait;
-    private closeCurrentSocket;
-}

package/dist/relay/relay-service.d.ts

@@ -1,19 +0,0 @@
-import { ApiClient } from '../http/api-client.js';
-export type RelayClientKind = 'cli' | 'web' | 'mobile' | 'voice';
-export interface RelayRegistration {
-    userSessionId: string;
-    relayToken: string;
-    relayTokenExpiresIn: number;
-    relayWsPath: string;
-    relayHeartbeatIntervalSec: number;
-}
-export interface RelayTokenRefresh {
-    relayToken: string;
-    relayTokenExpiresIn: number;
-}
-export interface RegisterRelayOptions {
-    userSessionId: string;
-    clientKind?: RelayClientKind;
-}
-export declare function registerRelaySession(client: ApiClient, accessToken: string, options: RegisterRelayOptions): Promise<RelayRegistration>;
-export declare function refreshRelayToken(client: ApiClient, accessToken: string, relayToken: string): Promise<RelayTokenRefresh>;

package/dist/schemas/index.d.ts

@@ -1,2 +0,0 @@
-export type { ControlMessage, MessageEnvelope, ControlMessageSchema, MessageEnvelopeSchema, MachineMessage, ValidationError, } from '@omnara/shared-js/schemas';
-export { validateControlMessage, validateMessageEnvelope, validateMachineMessage, } from '@omnara/shared-js/schemas';

package/dist/utils/backoff.d.ts

@@ -1,6 +0,0 @@
-export declare const INITIAL_RETRY_DELAY_MS = 1000;
-export declare const MAX_RETRY_DELAY_MS = 30000;
-/**
- * Calculates next delay with exponential backoff and jitter.
- */
-export declare function calculateBackoff(currentDelayMs: number): number;

package/dist/utils/browser.d.ts

@@ -1 +0,0 @@
-export declare function tryOpenBrowser(url: string): void;

package/dist/utils/claude-code-check.d.ts

@@ -1,19 +0,0 @@
-/**
- * Finds the path to the Claude Code executable.
- *
- * When running from a Bun single-file executable, the SDK's default resolution
- * fails because it looks for cli.js relative to the bundled module location,
- * which points to Bun's virtual filesystem (/$bunfs/root/cli.js).
- *
- * For Bun SFE, we MUST find the real claude executable via `which`.
- * For Node.js, we can let the SDK handle it (return empty object).
- */
-export declare function claudeExecutablePath(): {
-    pathToClaudeCodeExecutable?: string;
-};
-/**
- * Performs the Claude Code check and displays warning if needed
- * @param options - Optional configuration for the check
- * @returns boolean indicating if either authentication method is available
- */
-export declare function performClaudeCodeCheck(): Promise<boolean>;

package/dist/utils/executable.d.ts

@@ -1,53 +0,0 @@
-/**
- * Utilities for handling Bun single-file executable (SFE) detection and spawning.
- *
- * BACKGROUND (from Bun docs and GitHub issues):
- * When Bun compiles a script into a single-file executable, it creates a virtual
- * filesystem at /$bunfs/root/ where the embedded code lives. This means:
- *
- * When running as a Bun SFE:
- *   - process.execPath = /path/to/omnara (the compiled binary)
- *   - process.argv[0] = "bun"
- *   - process.argv[1] = "/$bunfs/root/omnara-darwin-arm64" (virtual filesystem path)
- *
- * When running via Node.js or `bun run`:
- *   - process.execPath = /usr/bin/node or /path/to/bun
- *   - process.argv[0] = same as execPath
- *   - process.argv[1] = /path/to/cli.js (the actual script file)
- *
- * KEY INSIGHT (from Jarred Sumner, Bun team):
- * - For the executable path, use `process.execPath`
- * - The /$bunfs/ path is NOT a usable filesystem location
- *
- * DETECTION:
- * Check if process.argv[1] starts with "/$bunfs/" to detect SFE mode.
- *
- * SPAWNING:
- * In SFE mode: spawn(process.execPath, ['daemon', 'run-service'])
- * In script mode: spawn(process.execPath, [process.argv[1], 'daemon', 'run-service'])
- *
- * References:
- * - https://bun.com/docs/bundler/executables
- * - https://github.com/oven-sh/bun/issues/8476
- */
-/**
- * Detects if running as a Bun single-file executable.
- * In Bun SFE, process.argv[1] points to Bun's virtual filesystem (/$bunfs/root/...).
- *
- * This is the official detection method per Bun documentation and GitHub issues.
- */
-export declare function isBunSingleFileExecutable(): boolean;
-/**
- * Gets the arguments needed to spawn a new instance of this CLI.
- * For Bun SFE, returns just the command args.
- * For Node.js, prepends the script path.
- *
- * @param commandArgs - The CLI command and arguments (e.g., ['daemon', 'run-service'])
- * @returns The full args array to pass to spawn(process.execPath, args)
- */
-export declare function getSpawnArgs(commandArgs: string[]): string[];
-/**
- * Gets the executable path for spawning a new instance of this CLI.
- * Always returns process.execPath (works for both Node.js and Bun SFE).
- */
-export declare function getExecutablePath(): string;

package/dist/utils/logger.d.ts

@@ -1,143 +0,0 @@
-/**
- * Logger utility for controlling console output based on environment
- *
- * Production detection:
- * 1. NODE_ENV === 'production'
- * 2. OMNARA_LOG_LEVEL === 'none' or 'error'
- * 3. Running from compiled dist/ directory (not tsx/ts-node)
- */
-import type { InspectOptions } from 'util';
-/**
- * Log levels for controlling output verbosity
- */
-export declare enum LogLevel {
-    NONE = 0,
-    ERROR = 1,
-    WARN = 2,
-    INFO = 3,
-    DEBUG = 4,
-    VERBOSE = 5
-}
-/**
- * Detects if the CLI is running in production mode
- */
-export declare function isProduction(): boolean;
-/**
- * Gets the current log level from environment or defaults
- */
-export declare function getLogLevel(): LogLevel;
-/**
- * Logger interface that extends Console but can be controlled
- */
-export interface Logger extends Console {
-    important(...args: unknown[]): void;
-    success(...args: unknown[]): void;
-    close?(): Promise<void>;
-}
-/**
- * Creates a controlled logger instance
- */
-type LogSink = (entry: {
-    line: string;
-    raw: unknown[];
-}) => void;
-export declare class ControlledLogger implements Logger {
-    private logLevel;
-    private forceOutput;
-    private _console;
-    private sinks;
-    private closers;
-    private formatLine;
-    Console: typeof console.Console;
-    constructor(options?: {
-        logLevel?: LogLevel;
-        forceOutput?: boolean;
-        sinks?: LogSink[];
-        closers?: Array<() => Promise<void> | void>;
-    });
-    /**
-     * Standard log output (INFO level)
-     */
-    log(...args: unknown[]): void;
-    /**
-     * Error output (always shown unless NONE)
-     */
-    error(...args: unknown[]): void;
-    /**
-     * Warning output
-     */
-    warn(...args: unknown[]): void;
-    /**
-     * Info level output
-     */
-    info(...args: unknown[]): void;
-    /**
-     * Debug output (only in development)
-     */
-    debug(...args: unknown[]): void;
-    /**
-     * Verbose/trace output
-     */
-    trace(...args: unknown[]): void;
-    /**
-     * Important messages that should always be shown to user
-     * (authentication status, connection info, etc.)
-     */
-    important(...args: unknown[]): void;
-    /**
-     * Success messages that should typically be shown
-     */
-    success(...args: unknown[]): void;
-    close(): Promise<void>;
-    /**
-     * Check if a message should be logged at the given level
-     */
-    private shouldLog;
-    private write;
-    /**
-     * Update the log level dynamically
-     */
-    setLogLevel(level: LogLevel): void;
-    /**
-     * Get current log level
-     */
-    getLogLevel(): LogLevel;
-    assert(condition?: boolean, ...data: unknown[]): void;
-    clear(): void;
-    count(label?: string): void;
-    countReset(label?: string): void;
-    dir(item?: unknown, options?: InspectOptions): void;
-    dirxml(...data: unknown[]): void;
-    group(...data: unknown[]): void;
-    groupCollapsed(...data: unknown[]): void;
-    groupEnd(): void;
-    table(tabularData?: unknown, properties?: string[]): void;
-    time(label?: string): void;
-    timeEnd(label?: string): void;
-    timeLog(label?: string, ...data: unknown[]): void;
-    timeStamp(label?: string): void;
-    profile(label?: string): void;
-    profileEnd(label?: string): void;
-}
-/**
- * Global logger instance
- */
-export declare const logger: ControlledLogger;
-/**
- * Creates a logger for a specific component
- */
-export declare function createLogger(componentName?: string, options?: {
-    logLevel?: LogLevel;
-    forceOutput?: boolean;
-    sinks?: LogSink[];
-    closers?: Array<() => Promise<void> | void>;
-}): Logger;
-/**
- * Helper to extract error messages consistently
- */
-export declare function extractErrorMessage(error: unknown): string;
-/**
- * Print current logger configuration (useful for debugging)
- */
-export declare function printLoggerConfig(): void;
-export {};

package/dist/utils/prompt.d.ts

@@ -1 +0,0 @@
-export declare function prompt(question: string): Promise<string>;

package/dist/utils/version-check.d.ts

@@ -1,47 +0,0 @@
-export declare const IS_PRERELEASE: boolean;
-/**
- * Detects if the CLI was installed via npm (not as a standalone binary).
- */
-export declare function isNpmInstallation(): boolean;
-/**
- * Runs the installation script to install/update the binary version.
- * Returns true if installation succeeded.
- * Passes PRERELEASE=1 env var to install script if in prerelease mode.
- *
- * @param options.silent - If true, suppress output (for daemon background updates)
- */
-export declare function runInstallScript(options?: {
-    silent?: boolean;
-}): Promise<boolean>;
-/**
- * Handles npm installation: show warning and migrate to binary.
- */
-export declare function handleNpmInstallation(): Promise<boolean>;
-/**
- * Checks if an update is available.
- * Checks prerelease channel if PRERELEASE=1 env var is set.
- */
-export declare function checkForUpdate(): Promise<{
-    available: boolean;
-    latestVersion?: string;
-    currentVersion: string;
-    isPrerelease: boolean;
-}>;
-/**
- * Performs an update by running the install script.
- * Used by both CLI and daemon for updates.
- */
-export declare function performUpdate(options?: {
-    silent?: boolean;
-}): Promise<boolean>;
-/**
- * Background update check for the daemon.
- * Checks for updates and triggers install script if available.
- */
-export declare function daemonUpdateCheck(): Promise<boolean>;
-/**
- * Checks for updates and performs auto-update if available.
- * Called when CLI starts.
- * Returns true if an update was installed and the CLI should exit.
- */
-export declare function attemptUpdate(): Promise<boolean>;

package/dist/utils/websocket.d.ts

@@ -1,5 +0,0 @@
-import WebSocket from 'ws';
-/**
- * Safely closes a WebSocket without throwing or emitting unhandled errors.
- */
-export declare function safeCloseWebSocket(ws: WebSocket): void;

package/instrument.mjs

@@ -1,14 +0,0 @@
-import * as Sentry from '@sentry/node';
-
-const DEFAULT_DSN =
-  'https://ad24dca67a2ab987c433aba53f738743@o4509630021828608.ingest.us.sentry.io/4510413097467904';
-
-const dsn = process.env.OMNARA_SENTRY_DSN ?? process.env.SENTRY_DSN ?? DEFAULT_DSN;
-
-if (dsn) {
-  Sentry.init({
-    dsn,
-    environment: process.env.OMNARA_ENV ?? process.env.NODE_ENV ?? 'production',
-    sendDefaultPii: false,
-  });
-}