edsger 0.76.0 → 0.78.0

package/dist/skills/phase/user-stories-analysis/SKILL.md

@@ -1,118 +0,0 @@
----
-description: Analyze a issue and generate comprehensive, professional user stories
-kind: phase
-user-invocable: false
----
-
-You are a **Senior Product Manager** specializing in writing professional, detailed user stories. Your task is to analyze a issue and generate comprehensive, high-quality user stories.
-
-**Your Role**: You are an expert product manager conducting rigorous business analysis. You think like a PM who has shipped products at top tech companies. You write user stories that engineers love because they are clear, specific, and leave no ambiguity.
-
-CRITICAL: You are NOT a software engineer. You should NEVER write code, build projects, or modify files. Your role is PURELY analytical - focus on understanding the issue requirements and creating professional user stories.
-
-**Professional User Story Format**:
-Every user story you create MUST follow this professional format:
-
-1. **Sequential ID**: A unique identifier with a prefix derived from the issue name (e.g., "PR-001" for "Potential Risk" issue, "CL-001" for "Conversation Lens" issue). Use a 2-3 letter abbreviation of the issue name.
-
-2. **Shortname**: A concise 2-5 word name that captures the essence of the story (e.g., "Risk Tab Access", "Beta Issue Awareness").
-
-3. **Category/Group**: Stories should be logically grouped by functional area (e.g., "Core Interface & Navigation", "Data Display & Visualization", "Configuration & Settings").
-
-4. **User Story Statement**: The standard format: "As a **[specific role]**, I would like **[specific goal/action]** so that **[specific business value/benefit]**."
-   - Be SPECIFIC about the role (not just "user" - use "manager", "admin", "coach", "analyst", etc.)
-   - Be SPECIFIC about the goal (not vague desires - concrete actions)
-   - Be SPECIFIC about the benefit (measurable or observable outcomes)
-
-5. **Description**: A detailed paragraph (2-4 sentences) that provides context and explains the story in depth. This should describe what the issue does, how it integrates with existing functionality, and why it matters.
-
-6. **Requirements**: A bulleted list of 4-8 specific, testable implementation requirements. Each requirement should be:
-   - Concrete and unambiguous
-   - Testable (you can verify if it's done or not)
-   - Independent enough to be a checklist item
-   - Written from a user/business perspective (not technical implementation details)
-
-**INVEST Principles**:
-Every user story MUST follow the INVEST criteria:
-
-- **Independent**: Self-contained, no dependencies on other stories
-- **Negotiable**: Flexible for discussion, focuses on "what" and "why"
-- **Valuable**: Clear business value to end users
-- **Estimable**: Clear enough for teams to estimate effort
-- **Small**: Completable within a single sprint
-- **Testable**: Clear acceptance criteria via the requirements list
-
-**Analysis Process**:
-
-1. **Understand the Issue**: Deeply analyze the issue description, product context, and any images/screenshots
-2. **Identify User Personas**: Determine all relevant user types/roles who interact with this issue
-3. **Map User Journeys**: Think through complete user workflows and interactions
-4. **Identify Functional Areas**: Group related functionality into categories
-5. **Review Existing Stories**: Check for duplicates and gaps in existing user stories
-6. **Create Stories**: Write professional stories following the format above
-7. **Validate Coverage**: Ensure all aspects of the issue are covered
-
-**Business Analysis Focus**:
-
-- Different user personas and their specific needs
-- Core functionality and navigation flows
-- Data display, filtering, and interaction patterns
-- Configuration, settings, and customization options
-- Error handling and edge cases from a user perspective
-- Accessibility and usability considerations
-- Integration with existing issues and workflows
-
-**Important Guidelines**:
-
-- All issue information, product context, and existing user stories are provided in the prompt
-- Do NOT attempt to read source code files or run any commands
-- Do NOT use tools like Bash, Read, Glob, Write, TodoWrite, or any other tools
-- Focus exclusively on creating high-quality, professional user stories
-- Avoid duplicating existing user stories
-- Think about ALL user personas, not just the primary one
-
-**Artifact Deletion Capability**:
-You can delete existing draft user stories that are:
-
-- **Duplicates**: Already covered by other stories
-- **No longer relevant**: Issue requirements changed
-- **Low quality**: Don't meet professional standards
-- **Addressed by feedback**: Explicitly requested for deletion
-
-**IMPORTANT DELETION RESTRICTIONS**:
-
-- You can ONLY delete artifacts with status 'draft'
-- Only artifacts marked with [DELETABLE] in the context can be deleted
-- Each deletable artifact includes an "ID:" field with the UUID
-- You MUST NOT delete, recreate, or modify artifacts marked with [APPROVED - DO NOT MODIFY]. These have been human-approved and are immutable. Do not create new stories that duplicate approved ones.
-
-To delete artifacts:
-
-1. Find the exact UUID from the "ID:" field
-2. Put ONLY the UUID string in the deleted_user_story_ids array
-3. Put the deletion reason in the deletion_reasons object
-
-**MANDATORY Checklist Compliance**:
-If you are provided with checklists in the context, you MUST satisfy ALL of them during your analysis work. Checklists are mandatory requirements that define quality standards and cannot be ignored or skipped.
-
-- Review each checklist carefully and ensure your analysis work addresses every requirement
-- You MUST include ALL provided checklist item IDs in the "checklist_item_results" field of your JSON response
-- CRITICAL: Use the exact UUID from the "ID:" field in each checklist ITEM, NOT the item title or description
-- Set "is_passed": true for each checklist item you have completed successfully
-- Provide appropriate "value" based on the item type (boolean: true/false, text: descriptive text, number: numeric value)
-- If you cannot satisfy a checklist item requirement, set "is_passed": false and explain why in the "notes" field
-- The system will validate that all checklist items have been addressed - missing items will cause the pipeline to fail
-
-CRITICAL: Checklists are not optional suggestions - they are mandatory quality gates that must be satisfied.
-
-**Quality Standards**:
-
-- Each story should have a unique, descriptive shortname (2-5 words)
-- Sequential IDs must be consistent (XX-001, XX-002, etc.)
-- Categories should logically group related stories
-- Requirements should be specific, testable, and user-focused
-- Description should provide enough context for any team member to understand
-- Stories should cover different user personas comprehensively
-- Aim for 8-20 stories per issue depending on complexity
-
-Focus on systematic analysis based on the provided context information.

package/dist/supabase/client.d.ts

@@ -1,34 +0,0 @@
-/**
- * Shared Supabase SDK client for direct-RLS calls from the CLI.
- *
- * See packages/edsger-agents/src/supabase/client.ts for the full design
- * notes (refresh ownership, file-watcher invalidation, etc.) — both packages
- * follow the same pattern so they stay in sync.
- */
-import { type SupabaseClient } from '@supabase/supabase-js';
-/**
- * Get (or lazily create) the shared SupabaseClient.
- *
- * Throws if the desktop-app has not yet synced a session. Callers should
- * catch this and fall back to the MCP edge function path for endpoints not
- * yet migrated.
- */
-export declare function getSupabase(): SupabaseClient;
-/**
- * Returns true if the desktop-app has synced a Supabase session that's
- * usable for direct-SDK calls.
- */
-export declare function hasSupabaseSession(): boolean;
-/**
- * Wait for the most recent setSession to finish applying, then report whether
- * the client actually holds a usable user session.
- *
- * Returns false when the synced token was stale/expired and supabase-js
- * dropped the session — in that state REST calls run as `anon` (auth.uid() is
- * NULL) and any insert into an RLS table with `WITH CHECK (auth.uid() =
- * user_id)` is rejected. Writers should gate the direct-SDK path on this and
- * fall back to the MCP edge function (service-role) when it returns false.
- */
-export declare function ensureSupabaseSession(): Promise<boolean>;
-/** Reset module state. Test-only. */
-export declare function resetSupabaseClient(): void;

package/dist/supabase/client.js

@@ -1,123 +0,0 @@
-/**
- * Shared Supabase SDK client for direct-RLS calls from the CLI.
- *
- * See packages/edsger-agents/src/supabase/client.ts for the full design
- * notes (refresh ownership, file-watcher invalidation, etc.) — both packages
- * follow the same pattern so they stay in sync.
- */
-import { createClient } from '@supabase/supabase-js';
-import { watch } from 'fs';
-import { homedir } from 'os';
-import { join } from 'path';
-import { getAccessToken, getRefreshToken, getSupabaseAnonKey, getSupabaseUrl, invalidateAuthCache, } from '../auth/auth-store.js';
-const AUTH_FILE = join(homedir(), '.edsger', 'auth.json');
-let _client = null;
-let _watcherInstalled = false;
-let _lastAppliedAccessToken;
-/** The in-flight setSession promise, awaited by ensureSupabaseSession(). */
-let _sessionReady = null;
-/**
- * Get (or lazily create) the shared SupabaseClient.
- *
- * Throws if the desktop-app has not yet synced a session. Callers should
- * catch this and fall back to the MCP edge function path for endpoints not
- * yet migrated.
- */
-export function getSupabase() {
-    if (_client) {
-        return _client;
-    }
-    const url = getSupabaseUrl();
-    const anonKey = getSupabaseAnonKey();
-    const accessToken = getAccessToken();
-    const refreshToken = getRefreshToken();
-    if (!url || !anonKey || !accessToken) {
-        throw new Error('Supabase session unavailable. Sign in to the Edsger desktop app to authorize the CLI.');
-    }
-    _client = createClient(url, anonKey, {
-        auth: {
-            persistSession: false,
-            autoRefreshToken: false,
-            detectSessionInUrl: false,
-        },
-    });
-    // Capture the setSession promise so writers can await it (via
-    // ensureSupabaseSession) before issuing inserts. Without this, the first
-    // REST call can race ahead of setSession and go out as `anon` (no user
-    // JWT), tripping the `auth.uid() = user_id` RLS check.
-    _sessionReady = _client.auth.setSession({
-        access_token: accessToken,
-        refresh_token: refreshToken ?? '',
-    });
-    _lastAppliedAccessToken = accessToken;
-    installAuthWatcher();
-    return _client;
-}
-/**
- * Returns true if the desktop-app has synced a Supabase session that's
- * usable for direct-SDK calls.
- */
-export function hasSupabaseSession() {
-    return Boolean(getSupabaseUrl() && getSupabaseAnonKey() && getAccessToken());
-}
-/**
- * Wait for the most recent setSession to finish applying, then report whether
- * the client actually holds a usable user session.
- *
- * Returns false when the synced token was stale/expired and supabase-js
- * dropped the session — in that state REST calls run as `anon` (auth.uid() is
- * NULL) and any insert into an RLS table with `WITH CHECK (auth.uid() =
- * user_id)` is rejected. Writers should gate the direct-SDK path on this and
- * fall back to the MCP edge function (service-role) when it returns false.
- */
-export async function ensureSupabaseSession() {
-    if (!hasSupabaseSession()) {
-        return false;
-    }
-    try {
-        const client = getSupabase();
-        if (_sessionReady) {
-            await _sessionReady;
-        }
-        const { data } = await client.auth.getSession();
-        return Boolean(data.session?.access_token);
-    }
-    catch {
-        return false;
-    }
-}
-function installAuthWatcher() {
-    if (_watcherInstalled) {
-        return;
-    }
-    _watcherInstalled = true;
-    try {
-        const watcher = watch(AUTH_FILE, () => {
-            invalidateAuthCache();
-            const nextAccess = getAccessToken();
-            const nextRefresh = getRefreshToken();
-            if (!_client ||
-                !nextAccess ||
-                nextAccess === _lastAppliedAccessToken) {
-                return;
-            }
-            _lastAppliedAccessToken = nextAccess;
-            _sessionReady = _client.auth.setSession({
-                access_token: nextAccess,
-                refresh_token: nextRefresh ?? '',
-            });
-            _client.realtime.setAuth(nextAccess);
-        });
-        watcher.unref();
-    }
-    catch {
-        // File missing or watch unsupported — best effort.
-    }
-}
-/** Reset module state. Test-only. */
-export function resetSupabaseClient() {
-    _client = null;
-    _watcherInstalled = false;
-    _lastAppliedAccessToken = undefined;
-    _sessionReady = null;
-}

package/dist/system/session-manager.d.ts

@@ -1,67 +0,0 @@
-/**
- * Session Manager - Registers and maintains CLI session state with the server
- *
- * Enables:
- * - Web dashboard to see running CLI instances
- * - Remote start/stop/pause control of CLI processing
- * - Heartbeat to keep session alive
- */
-export type SessionStatus = 'running' | 'paused' | 'stopped';
-export interface CliSession {
-    sessionId: string;
-    hostname: string;
-    version: string;
-    status: SessionStatus;
-    startedAt: string;
-    lastHeartbeat: string;
-    currentIssueId?: string;
-    currentIssueName?: string;
-}
-/**
- * Register this CLI session with the server.
- * Optionally accepts command name and product ID for filtering on detail pages.
- *
- * Idempotent: if a session is already active (e.g. registered by the top-level
- * command hook), this enriches that row with the command/product instead of
- * creating a second session, and returns the existing id.
- *
- * The stored `command` is the desktop process key when the CLI was spawned by
- * the app (EDSGER_PROCESS_KEY), so a feature/tab can find this session; see
- * `resolvedCommand`.
- */
-export declare function registerSession(options?: {
-    command?: string;
-    productId?: string;
-}): Promise<string>;
-/**
- * Send a heartbeat to keep the session alive and check for commands
- */
-export declare function sendHeartbeat(currentIssueId?: string, currentIssueName?: string): Promise<SessionStatus>;
-/**
- * Start periodic heartbeats
- */
-export declare function startHeartbeat(): void;
-/**
- * Stop periodic heartbeats
- */
-export declare function stopHeartbeat(): void;
-/**
- * Deregister this CLI session
- */
-export declare function deregisterSession(): Promise<void>;
-/**
- * Get current session status
- */
-export declare function getSessionStatus(): SessionStatus;
-/**
- * Set session status locally (before next heartbeat syncs it)
- */
-export declare function setSessionStatus(status: SessionStatus): void;
-/**
- * Get current session ID
- */
-export declare function getSessionId(): string | null;
-/**
- * Check if the session should be processing (not paused or stopped)
- */
-export declare function shouldProcess(): boolean;

package/dist/system/session-manager.js

@@ -1,300 +0,0 @@
-/**
- * Session Manager - Registers and maintains CLI session state with the server
- *
- * Enables:
- * - Web dashboard to see running CLI instances
- * - Remote start/stop/pause control of CLI processing
- * - Heartbeat to keep session alive
- */
-import { hostname } from 'os';
-import { callMcpEndpoint } from '../api/mcp-client.js';
-import { getUserId } from '../auth/auth-store.js';
-import { getVersion } from '../constants.js';
-import { ensureSupabaseSession, getSupabase, hasSupabaseSession, } from '../supabase/client.js';
-import { initLogSync, logInfo, logWarning, stopLogSync, } from '../utils/logger.js';
-let currentSessionId = null;
-let heartbeatTimer;
-let _sessionStatus = 'running';
-/** How often to send heartbeats (30 seconds) */
-const HEARTBEAT_INTERVAL = 30_000;
-/**
- * Generate a unique session ID
- */
-function generateSessionId() {
-    const timestamp = Date.now().toString(36);
-    const random = Math.random().toString(36).substring(2, 8);
-    return `cli-${timestamp}-${random}`;
-}
-/**
- * The value stored in `cli_sessions.command`.
- *
- * When the desktop app spawns a streamed CLI it injects EDSGER_PROCESS_KEY --
- * its process-registry key (`:output` channel marker already stripped), e.g.
- * `sync-terraform`, `recipes:<productId>`, `pr-review:<prId>`. That key is what
- * the originating tab looks up by, so it takes precedence over the bare command
- * name; standalone runs fall back to the supplied command name.
- */
-function resolvedCommand(options) {
-    return process.env.EDSGER_PROCESS_KEY || options?.command;
-}
-/**
- * Register this CLI session with the server.
- * Optionally accepts command name and product ID for filtering on detail pages.
- *
- * Idempotent: if a session is already active (e.g. registered by the top-level
- * command hook), this enriches that row with the command/product instead of
- * creating a second session, and returns the existing id.
- *
- * The stored `command` is the desktop process key when the CLI was spawned by
- * the app (EDSGER_PROCESS_KEY), so a feature/tab can find this session; see
- * `resolvedCommand`.
- */
-export async function registerSession(options) {
-    // Already in a session for this process — enrich, don't double-register.
-    if (currentSessionId) {
-        await enrichSession(options);
-        return currentSessionId;
-    }
-    const sessionId = generateSessionId();
-    currentSessionId = sessionId;
-    const command = resolvedCommand(options);
-    // Full invocation (subcommand + args) for readable run history. `command`
-    // stays the stable, entity-scoped lookup key; this carries the variable args.
-    const invocation = process.argv.slice(2).join(' ') || undefined;
-    try {
-        const userId = getUserId();
-        // ensureSupabaseSession() awaits the in-flight setSession and confirms the
-        // client holds a live user session — so a token that hasn't applied yet
-        // (race) or was dropped (stale → anon) doesn't silently write as anon and
-        // trip the cli_sessions RLS check. The desktop refreshes the token into
-        // auth.json before spawning the CLI, so this should hold for app-spawned
-        // runs; the MCP branch stays for the legacy no-Supabase-session path.
-        if (userId && (await ensureSupabaseSession())) {
-            const row = {
-                session_id: sessionId,
-                user_id: userId,
-                hostname: hostname(),
-                version: getVersion(),
-                status: 'running',
-                started_at: new Date().toISOString(),
-                last_heartbeat: new Date().toISOString(),
-            };
-            if (command) {
-                row.command = command;
-            }
-            if (invocation) {
-                row.invocation = invocation;
-            }
-            if (options?.productId) {
-                row.product_id = options.productId;
-            }
-            const { error } = await getSupabase()
-                .from('cli_sessions')
-                .upsert(row, { onConflict: 'session_id' });
-            if (error) {
-                throw new Error(error.message);
-            }
-        }
-        else {
-            const payload = {
-                session_id: sessionId,
-                hostname: hostname(),
-                version: getVersion(),
-                status: 'running',
-            };
-            if (command) {
-                payload.command = command;
-            }
-            if (invocation) {
-                payload.invocation = invocation;
-            }
-            if (options?.productId) {
-                payload.product_id = options.productId;
-            }
-            await callMcpEndpoint('cli_sessions/register', payload);
-        }
-        logInfo(`CLI session registered: ${sessionId}`);
-    }
-    catch {
-        // Session registration is best-effort, don't fail
-        logWarning('Could not register CLI session with server');
-    }
-    // Start log sync after session registration
-    initLogSync(sessionId);
-    return sessionId;
-}
-/**
- * Best-effort enrichment of the already-active session row with command /
- * product info (e.g. when a command registers itself after the top-level hook
- * already opened the session). Direct-SDK path only; the MCP heartbeat path
- * keeps whatever the initial register supplied.
- */
-async function enrichSession(options) {
-    const command = resolvedCommand(options);
-    if (!currentSessionId || (!command && !options?.productId)) {
-        return;
-    }
-    try {
-        const userId = getUserId();
-        if (!hasSupabaseSession() || !userId) {
-            return;
-        }
-        const patch = {};
-        // With a desktop process key present, `command` resolves to that key, so
-        // a self-registering command can't clobber it with its bare name.
-        if (command) {
-            patch.command = command;
-        }
-        if (options?.productId) {
-            patch.product_id = options.productId;
-        }
-        await getSupabase()
-            .from('cli_sessions')
-            .update(patch)
-            .eq('session_id', currentSessionId)
-            .eq('user_id', userId);
-    }
-    catch {
-        // best-effort
-    }
-}
-/**
- * Send a heartbeat to keep the session alive and check for commands
- */
-export async function sendHeartbeat(currentIssueId, currentIssueName) {
-    if (!currentSessionId) {
-        return 'running';
-    }
-    try {
-        let serverStatus;
-        const userId = getUserId();
-        if (hasSupabaseSession() && userId) {
-            // Single UPDATE...RETURNING reads back the row's current status, which
-            // the dashboard may have flipped to 'paused' / 'stopped' since the
-            // last heartbeat.
-            const { data, error } = await getSupabase()
-                .from('cli_sessions')
-                .update({
-                last_heartbeat: new Date().toISOString(),
-                version: getVersion(),
-                current_issue_id: currentIssueId ?? null,
-                current_issue_name: currentIssueName ?? null,
-            })
-                .eq('session_id', currentSessionId)
-                .eq('user_id', userId)
-                .select('status')
-                .maybeSingle();
-            if (error) {
-                throw new Error(error.message);
-            }
-            serverStatus = data?.status ?? undefined;
-        }
-        else {
-            const result = (await callMcpEndpoint('cli_sessions/heartbeat', {
-                session_id: currentSessionId,
-                version: getVersion(),
-                status: _sessionStatus,
-                current_issue_id: currentIssueId,
-                current_issue_name: currentIssueName,
-            }));
-            serverStatus = result.status;
-        }
-        // Server may respond with a new status (e.g., 'paused' or 'stopped')
-        if (serverStatus && serverStatus !== _sessionStatus) {
-            logInfo(`Session status changed: ${_sessionStatus} -> ${serverStatus}`);
-            _sessionStatus = serverStatus;
-        }
-        return _sessionStatus;
-    }
-    catch {
-        // Heartbeat failure is non-fatal
-        return _sessionStatus;
-    }
-}
-/**
- * Start periodic heartbeats
- */
-export function startHeartbeat() {
-    if (heartbeatTimer) {
-        return;
-    }
-    heartbeatTimer = setInterval(() => {
-        sendHeartbeat().catch(() => {
-            /* noop */
-        });
-    }, HEARTBEAT_INTERVAL);
-    // The heartbeat alone must never keep a finished command's process alive.
-    heartbeatTimer.unref?.();
-}
-/**
- * Stop periodic heartbeats
- */
-export function stopHeartbeat() {
-    if (heartbeatTimer) {
-        clearInterval(heartbeatTimer);
-        heartbeatTimer = undefined;
-    }
-}
-/**
- * Deregister this CLI session
- */
-export async function deregisterSession() {
-    if (!currentSessionId) {
-        return;
-    }
-    stopHeartbeat();
-    // Flush remaining logs before deregistering
-    await stopLogSync();
-    try {
-        const userId = getUserId();
-        if (hasSupabaseSession() && userId) {
-            // Match the MCP handler's behaviour: keep the row so historical logs
-            // can still link to it, just mark it stopped + clear current issue.
-            const { error } = await getSupabase()
-                .from('cli_sessions')
-                .update({
-                status: 'stopped',
-                current_issue_id: null,
-                current_issue_name: null,
-            })
-                .eq('session_id', currentSessionId)
-                .eq('user_id', userId);
-            if (error) {
-                throw new Error(error.message);
-            }
-        }
-        else {
-            await callMcpEndpoint('cli_sessions/deregister', {
-                session_id: currentSessionId,
-            });
-        }
-    }
-    catch {
-        // Best-effort
-    }
-    currentSessionId = null;
-}
-/**
- * Get current session status
- */
-export function getSessionStatus() {
-    return _sessionStatus;
-}
-/**
- * Set session status locally (before next heartbeat syncs it)
- */
-export function setSessionStatus(status) {
-    _sessionStatus = status;
-}
-/**
- * Get current session ID
- */
-export function getSessionId() {
-    return currentSessionId;
-}
-/**
- * Check if the session should be processing (not paused or stopped)
- */
-export function shouldProcess() {
-    return _sessionStatus === 'running';
-}

package/dist/system/sleep-notification.d.ts

@@ -1,15 +0,0 @@
-/**
- * Sleep Notification - Warns user when computer is about to sleep
- *
- * Uses OS-specific mechanisms to detect sleep events and show notifications:
- * - macOS: pmset log monitoring + osascript notifications
- * - Linux: dbus-monitor for sleep signals + notify-send
- */
-/**
- * Start monitoring for sleep events
- */
-export declare function startSleepMonitor(): void;
-/**
- * Stop monitoring for sleep events
- */
-export declare function stopSleepMonitor(): void;