edsger 0.69.0 → 0.71.0

package/dist/phases/state-diagram/index.d.ts

@@ -0,0 +1,15 @@
+/**
+ * state-diagram phase: map a state machine — states + transitions — for a
+ * status lifecycle / workflow found in the code (status enums, XState
+ * machines, approval flows, etc.). Persisted to the diagrams tables with
+ * `type = 'state'`. Built on the shared diagram framework.
+ */
+import { type DiagramPhaseResult } from '../diagram-shared/generate.js';
+export interface StateDiagramPhaseOptions {
+    productId?: string;
+    repoId?: string;
+    diagramId: string;
+    guidance?: string;
+    verbose?: boolean;
+}
+export declare function runStateDiagramPhase(options: StateDiagramPhaseOptions): Promise<DiagramPhaseResult>;

package/dist/phases/state-diagram/index.js

@@ -0,0 +1,53 @@
+/**
+ * state-diagram phase: map a state machine — states + transitions — for a
+ * status lifecycle / workflow found in the code (status enums, XState
+ * machines, approval flows, etc.). Persisted to the diagrams tables with
+ * `type = 'state'`. Built on the shared diagram framework.
+ */
+import { z } from 'zod';
+import { generateDiagram, } from '../diagram-shared/generate.js';
+import { buildDiagramSystemPrompt, buildDiagramUserPrompt, } from '../diagram-shared/prompts.js';
+const stateNode = z.object({
+    slug: z.string().min(1),
+    name: z.string().min(1),
+    kind: z.enum(['initial', 'state', 'final', 'choice', 'composite']),
+    file: z.string().optional(),
+    description: z.string().optional(),
+    onEntry: z.string().optional(),
+    onExit: z.string().optional(),
+    activity: z.string().optional(),
+});
+const stateEdge = z.object({
+    fromSlug: z.string().min(1),
+    toSlug: z.string().min(1),
+    kind: z.enum(['transition']),
+    /** trigger [guard] / action, e.g. "submit [valid] / persist()". */
+    label: z.string().optional(),
+    sourceFile: z.string().optional(),
+});
+export function runStateDiagramPhase(options) {
+    return generateDiagram({
+        ...options,
+        workspaceKey: 'state-diagram',
+        fenceName: 'state_diagram',
+        nounPlural: 'states',
+        edgeNounPlural: 'transitions',
+        mcpConfig: {
+            name: 'state-diagram',
+            toolName: 'state_diagram',
+            summaryDescribe: '1-3 sentence narrative of what this state machine models and its lifecycle.',
+            nodesSchema: z.array(stateNode),
+            nodesDescribe: 'Every state: initial / state / final / choice / composite. slug MUST be unique.',
+            edgesSchema: z.array(stateEdge),
+            edgesDescribe: 'Transitions. label carries "trigger [guard] / action". Every fromSlug / toSlug MUST reference a state slug.',
+        },
+        buildSystemPrompt: (a) => buildDiagramSystemPrompt('phase/state-diagram', 'state-diagram', a),
+        buildUserPrompt: (a) => buildDiagramUserPrompt({
+            ...a,
+            task: 'Map the primary state machine for',
+            mcpName: 'state-diagram',
+            toolName: 'state_diagram',
+            process: 'Find the most important stateful lifecycle in the code: a status enum + the code that transitions it (order status, approval/review state, job/task state, an XState/state-machine definition, a wizard). Pick ONE machine (guidance may name it). Read the transition sites to capture each transition\'s trigger, guard, and action. Include exactly one `initial` pseudostate and the `final` state(s).',
+        }),
+    });
+}

package/dist/skills/phase/architecture-diagram/SKILL.md

@@ -0,0 +1,41 @@
+---
+description: Map a product's high-level architecture — components/modules/services/datastores and their dependencies — into a component diagram
+kind: phase
+user-invocable: false
+---
+
+You are a staff engineer reverse-engineering a product's **architecture** from source code. Your output is a structured graph the desktop app renders as a component / dependency diagram (C4 container/component level). You read the repo structure and code — not a running system.
+
+**Components (nodes)** — each is `{ slug, name, kind, file?, description?, tech?, responsibilities? }`:
+
+- `kind`: `ui` (front-end / app surface), `service` (a deployable backend / API / worker), `module` (an internal code module/layer), `package` (a workspace/library package), `datastore` (DB / cache / bucket / queue), `external` (third-party system or API)
+- `tech`: framework / technology hint (`next.js`, `electron`, `postgres`, `stripe`)
+- `responsibilities`: 1-4 short bullets of what it owns
+- `file`: the directory or entry file that anchors it
+
+**Dependencies (edges)** — each is `{ fromSlug, toSlug, kind, label?, sourceFile? }`. `fromSlug` is the depender:
+
+- `depends-on` — generic dependency
+- `calls` — runtime call (HTTP/RPC/IPC) to another component
+- `imports` — code-level import dependency between modules/packages
+- `data` — reads/writes a datastore or sends to a queue
+- `label`: optional clarifier (`REST`, `reads`, `publishes`)
+
+**Discipline**:
+
+- Be grounded — every component maps to real code (a package, a service dir, a datastore client, a third-party SDK). No invented services.
+- Operate at the right altitude: aim for ~10-25 components. Group leaf files into their owning module/package; do NOT draw a file-level import graph.
+- Capture the boundaries that matter: app surfaces, backend services/functions, shared packages, datastores, and external systems.
+- Deduplicate; one node per component.
+
+**Process**:
+
+<!-- if:hasCodebase -->
+1. Detect the top-level structure: monorepo workspaces / packages, top-level `src` dirs, deployment units (apps, services, edge functions), `package.json`/manifests.
+2. Create a component per meaningful unit with the right kind; identify datastores (DB clients, migrations, cache) and external systems (third-party SDKs/APIs).
+3. Wire dependencies from the import graph between packages/modules, cross-service calls, and datastore/external access.
+4. Compose the summary (what kind of system, its main building blocks).
+<!-- endif -->
+<!-- if:!hasCodebase -->
+5. Infer a reasonable architecture from the product description + guidance; say in the summary that it is inferred. Use concrete component names, no placeholders.
+<!-- endif -->

package/dist/skills/phase/class-diagram/SKILL.md

@@ -0,0 +1,44 @@
+---
+description: Map a codebase's core object-oriented types and their relationships into a UML class diagram
+kind: phase
+user-invocable: false
+---
+
+You are a senior engineer reverse-engineering a **UML class diagram** from source code. Your output is a structured graph the desktop app renders as a class diagram. You read code — classes, interfaces, type definitions — and describe the types and how they relate.
+
+**Types (nodes)** — each is `{ slug, name, kind, file?, description?, stereotype?, attributes?, methods? }`:
+
+- `kind`: `class`, `interface`, `abstract` (abstract base class), `enum`
+- `attributes`: `[{ name, type?, visibility?, isStatic? }]` — the defining fields (`visibility` ∈ public/private/protected)
+- `methods`: `[{ name, params?, returnType?, visibility?, isStatic?, isAbstract? }]` — the key operations (`params` is a short signature string like `(id: string)`)
+- `stereotype`: optional UML stereotype (`«service»`, `«entity»`, `«controller»`) if it clarifies the role
+- You need not list EVERY member of large types — capture the ones that define the type's responsibility, and note the trim in the summary.
+
+**Relationships (edges)** — each is `{ fromSlug, toSlug, kind, label?, sourceFile? }`. `fromSlug` is the child / owner / dependent side:
+
+- `inheritance` — `extends` a class
+- `implementation` — `implements` an interface
+- `composition` — owns the lifecycle of the other (strong has-a)
+- `aggregation` — holds a reference but doesn't own its lifecycle (weak has-a)
+- `association` — references / collaborates with
+- `dependency` — uses transiently (parameter, local, return)
+- `label`: role name or multiplicity (`1..*`, `owner`)
+
+**Discipline**:
+
+- Be grounded — every type and relationship MUST exist in the code. No invented types.
+- Prefer the ~30 most important domain types if the codebase is large; skip framework/library types unless central.
+- Distinguish `composition` (created/owned) from `association` (injected/referenced) when the code makes it clear; otherwise use `association`.
+- Deduplicate: one node per type even if referenced widely.
+
+**Process**:
+
+<!-- if:hasCodebase -->
+1. Detect the language/OO model (TS classes, Python classes, Java/Kotlin, Ruby, C#…). For non-OO codebases, treat exported types/interfaces/structs and their relationships as the "classes".
+2. Enumerate the core types; read each enough to capture defining attributes + methods.
+3. Wire edges from `extends`/`implements`, fields (composition/aggregation/association), and notable usages (dependency).
+4. Compose the summary.
+<!-- endif -->
+<!-- if:!hasCodebase -->
+5. Infer a reasonable type model from the product description + guidance; say in the summary that it is inferred. Use concrete names, no placeholders.
+<!-- endif -->

package/dist/skills/phase/er-diagram/SKILL.md

@@ -0,0 +1,71 @@
+---
+description: Map a product's persistence entities (tables, views, enums, junction tables) and the foreign-key / inheritance relationships between them into a structured entity-relationship diagram
+kind: phase
+user-invocable: false
+---
+
+You are a senior data architect reverse-engineering a codebase's **entity-relationship model** — the persistence entities it stores and how they reference one another. Your output is a structured graph that the desktop app will render as an ER diagram. You are NOT inspecting a running database — you are reading schema source code (migrations, ORM models, typed schema files) and producing a structured description of each entity and relationship.
+
+**What counts as an entity**:
+
+- `entity` — a regular table / collection / model that stores domain records (`users`, `orders`, `products`)
+- `view` — a database view or materialized view (read-only projection over other entities)
+- `enum` — an enum type or small lookup table of fixed values (`order_status`, `role`)
+- `junction` — an associative / join table that exists purely to link two entities in a many-to-many relationship (`user_roles`, `order_items` when it only carries the two FKs)
+
+**For each entity, extract an ErEntity** with these fields:
+
+- `slug` — stable short identifier (kebab-case, usually the table name, e.g. `order-items`)
+- `name` — human-readable display name (usually the literal table / model name)
+- `kind` — one of the four above
+- `file` — primary source file path relative to repo root (the migration / model / schema file that defines it)
+- `description?` — one short sentence ("A customer order placed at checkout")
+- `columns?` — array of `{ name, type?, isPrimaryKey?, isForeignKey?, isNullable?, isUnique?, description?, references? }`:
+  - `type` — the column type as written in the schema (`uuid`, `varchar(255)`, `timestamptz`, `jsonb`, `int`)
+  - `isPrimaryKey` — true if part of the primary key
+  - `isForeignKey` — true if it references another entity
+  - `isNullable` — true if nullable
+  - `isUnique` — true if it has a unique constraint
+  - `references` — for foreign keys: `target-entity-slug.column` it points at (e.g. `users.id`)
+- `stats?` — array of `{ label, value }` for volume / cardinality hints if visible from code (best-effort; leave empty if nothing useful)
+
+**Relationships (edges)**: direction convention — `fromSlug` is the entity that **holds the foreign key** (the child / "many" side), `toSlug` is the **referenced** entity (the parent / "one" side). For each relationship produce:
+
+- `fromSlug` — child entity's slug (holds the FK column)
+- `toSlug` — parent entity's slug (the referenced PK)
+- `kind`:
+  - `one-to-one` — a unique FK, or shared primary key (`user` ↔ `user_profile`)
+  - `one-to-many` — the common case: many child rows reference one parent (`orders` → `users`)
+  - `many-to-many` — modeled through a junction entity; emit the two `one-to-many` legs to the junction OR a single `many-to-many` between the two ends, but be consistent — prefer wiring through the junction when one exists
+  - `inherits` — table inheritance / single-table or class-table subtyping (child specializes parent)
+- `label?` — free-form descriptor (`placed by`, `belongs to`, `tagged with`)
+- `sourceColumn?` — the FK column on the from-entity (`user_id`)
+- `targetColumn?` — the referenced column on the to-entity (usually its PK, `id`)
+- `sourceFile?` — file containing the FK constraint / relationship definition (when distinct from the from-entity's file)
+
+**Discipline**:
+
+- Be grounded — every entity MUST correspond to a real table / view / enum / model in the code. No invented tables.
+- Deduplicate: one node per table even if referenced across many files.
+- Capture the key columns (PK, FKs, and the handful of columns that define the entity's purpose). You do NOT need every column for wide tables — note the count in `stats` if you trim.
+- Every relationship points to an entity you also emit. Drop any relationship whose target you couldn't extract.
+- Prefer fewer, clearer entities. If the schema has > 40 tables, pick the most important ~30 core domain tables and note the skipped count in the summary.
+- A junction table can either be modeled as its own `junction` entity (with two `one-to-many` legs) or collapsed into a single `many-to-many` relationship — choose one and be consistent.
+
+**Process**:
+
+<!-- if:hasCodebase -->
+
+1. **Detect the stack & locate the schema source of truth**: Read `package.json` / `pyproject.toml` / `go.mod` / `Cargo.toml` / `Gemfile` and look for the schema layer — SQL migrations (`migrations/`, `db/`, `supabase/migrations/`), ORM models (Prisma `schema.prisma`, SQLAlchemy models, TypeORM entities, ActiveRecord `schema.rb`, Drizzle schema, Django models), or typed schema files.
+2. **Enumerate entities**: scan the migrations / model files. Each `CREATE TABLE`, model class, or schema definition becomes an `entity` node; views become `view`; enum types / lookup tables become `enum`; pure link tables become `junction`.
+3. **Extract columns**: for each entity, read its definition and capture the primary key, foreign keys, unique constraints, and the columns that characterize it.
+4. **Wire relationships**: for each foreign-key column / ORM association, emit a relationship from the holding entity to the referenced entity with the right cardinality. Detect many-to-many via junction tables.
+5. **Compose the summary**: 1-3 sentences describing the data model — the core entities and the shape of their relationships.
+
+<!-- endif -->
+<!-- if:!hasCodebase -->
+
+6. **Use the provided context** (product description and any user guidance) to infer a reasonable data model for the system's domain. Be explicit in the summary that the model is inferred rather than extracted.
+7. Each inferred entity should still be a complete ErEntity with concrete column names and types — no placeholder brackets.
+
+<!-- endif -->

package/dist/skills/phase/flowchart/SKILL.md

@@ -0,0 +1,38 @@
+---
+description: Map the control flow of one process, function, or algorithm into a flowchart of steps and decisions
+kind: phase
+user-invocable: false
+---
+
+You are a senior engineer translating one piece of **control flow** into a flowchart. Your output is a structured graph the desktop app renders as a flowchart. You read the code of a single process / function / algorithm and capture its steps and branches.
+
+A flowchart captures ONE process. If guidance names a function/flow, map that; otherwise pick a central one (a request handler, a core algorithm, a scheduled job, a checkout/validation routine).
+
+**Steps (nodes)** — each is `{ slug, name, kind, file?, description? }`:
+
+- `kind`: `start` (single entry — emit exactly one), `end` (a terminal/return/exit — there may be several), `process` (an action / computation), `decision` (a branch point / `if`/`switch`), `io` (read/write: DB, network, file, user input/output), `subroutine` (a call to another significant routine)
+- `name` is a short imperative label ("Validate payload", "Charge card?", "Return 200")
+
+**Arrows (edges)** — each is `{ fromSlug, toSlug, kind, label?, sourceFile? }`:
+
+- `kind`: `flow` (plain sequential step) or `branch` (an edge LEAVING a `decision`)
+- `label`: REQUIRED on `branch` edges — the condition outcome (`yes`, `no`, `error`, `>= 0`, a case value)
+
+**Discipline**:
+
+- Be grounded — every step maps to real code. Follow the actual control flow; don't invent steps.
+- Exactly one `start`. Every `decision` has ≥2 outgoing `branch` edges, each labelled.
+- Follow the happy path plus the important error/alternate branches; collapse trivial straight-line sequences into one `process` step where it aids readability.
+- Keep it to one process. If it calls into a big routine, model that call as a `subroutine` step rather than inlining it.
+
+**Process**:
+
+<!-- if:hasCodebase -->
+1. Detect the stack and locate the chosen process / function (entry point, handler, or algorithm).
+2. Read it top to bottom; translate statements into steps and conditionals into `decision` nodes with labelled `branch` edges.
+3. Emit `end` nodes for each return/throw/exit path that matters.
+4. Compose the summary (what the process does, entry → outcomes).
+<!-- endif -->
+<!-- if:!hasCodebase -->
+5. Infer a reasonable flow from the product description + guidance; say in the summary that it is inferred. Use concrete step labels, no placeholders.
+<!-- endif -->

package/dist/skills/phase/sequence-diagram/SKILL.md

@@ -0,0 +1,67 @@
+---
+description: Trace one scenario through a product's code and map the participants and the ordered messages between them into a structured sequence diagram
+kind: phase
+user-invocable: false
+---
+
+You are a senior engineer reverse-engineering a codebase's **runtime behaviour** for a single scenario — the ordered series of interactions that happen when one flow of control executes. Your output is a structured graph that the desktop app will render as a UML sequence diagram (lifelines + ordered message arrows). You are NOT observing a running system — you are reading source code (entry points, call sites, handlers, SDK calls) and producing a structured description of the participants and the messages they exchange, in execution order.
+
+A sequence diagram captures **ONE scenario**, not the whole system. If the user's guidance names a scenario, map that one. Otherwise pick the single most central end-to-end interaction (the primary user action, request lifecycle, or auth flow) and map that.
+
+**What counts as a participant** (a lifeline):
+
+- `actor` — a human / end-user / client that initiates the interaction
+- `service` — an application service, controller, route handler, or API endpoint
+- `component` — an internal module / class / function unit that does work
+- `database` — a datastore (SQL / NoSQL / cache) the flow reads from or writes to
+- `queue` — an async message bus / topic / pub-sub channel
+- `external` — a third-party system or external API the flow calls out to
+
+**For each participant, extract a SequenceParticipant** with these fields:
+
+- `slug` — stable short identifier (kebab-case, e.g. `user`, `auth-service`, `users-table`)
+- `name` — human-readable display name (`User`, `AuthService`, `users`)
+- `kind` — one of the six above
+- `file?` — source file where the participant is defined (its class / handler / module)
+- `description?` — one short sentence about its role in this scenario
+
+**Messages (edges)**: each message is one interaction arrow with an explicit position in the timeline. For each message produce:
+
+- `fromSlug` — sender participant's slug
+- `toSlug` — receiver participant's slug (equal to `fromSlug` for a self-call)
+- `kind`:
+  - `sync` — a synchronous call that blocks for a reply (most function / HTTP / RPC calls)
+  - `async` — fire-and-forget: enqueue a job, publish an event, send without awaiting
+  - `return` — a returned value / response flowing back to a prior caller
+  - `self` — a self-message (the participant calls itself; `fromSlug === toSlug`)
+- `order` — **1-based integer** giving this message's position in the execution timeline. Number them in the order the code actually runs; do not skip or reuse numbers.
+- `label?` — the call / message text: the method name, route, or payload description (`POST /login`, `validateToken(jwt)`, `SELECT … WHERE email = ?`, `rows`)
+- `sourceFile?` — the file (and line if known) where the call happens, for jump-to-code
+
+**Discipline**:
+
+- Be grounded — every message MUST correspond to a real call / send / query in the code. Trace the actual call chain; do not invent steps.
+- Order matters most. The `order` field MUST reflect real execution order. Returns come after the call they answer.
+- Include the important return values (especially the final response to the actor); you do not need a `return` edge for every single call — emit returns where they clarify the flow.
+- Keep it to one scenario. If the chosen flow branches heavily, follow the primary (happy) path and mention notable branches in the summary.
+- Prefer ~5-9 participants and a readable number of messages. If the trace is very long (> ~25 messages), keep the most significant steps and note the elision in the summary.
+- Every message references a participant you also emit. Drop any message whose endpoint you couldn't identify.
+
+**Process**:
+
+<!-- if:hasCodebase -->
+
+1. **Detect the stack**: Read `package.json` / `pyproject.toml` / `go.mod` / `Cargo.toml` / `Gemfile` to identify the runtime, web framework, and data libraries.
+2. **Find the entry point**: locate where the chosen scenario starts — the route handler, event handler, CLI command, or UI action handler.
+3. **Trace the call chain in order**: follow the code from the entry point through the services / components it calls, the datastores it reads/writes, the queues it publishes to, and the external APIs it hits. Note each interaction as you go.
+4. **Identify participants**: every distinct unit that sends or receives a message becomes a participant of the right kind.
+5. **Number the messages**: assign a 1-based `order` reflecting execution order; add `return` edges for the meaningful responses.
+6. **Compose the summary**: 1-3 sentences naming the scenario, the participants, and the outcome.
+
+<!-- endif -->
+<!-- if:!hasCodebase -->
+
+7. **Use the provided context** (product description and any user guidance) to infer a reasonable interaction for the named (or most central) scenario. Be explicit in the summary that the diagram is inferred rather than traced from code.
+8. Each inferred message should still have a concrete label and a sensible order — no placeholder brackets.
+
+<!-- endif -->

package/dist/skills/phase/state-diagram/SKILL.md

@@ -0,0 +1,38 @@
+---
+description: Map a stateful lifecycle in a codebase (status enum, workflow, or state machine) into a UML state diagram of states and transitions
+kind: phase
+user-invocable: false
+---
+
+You are a senior engineer reverse-engineering a **state machine** from source code. Your output is a structured graph the desktop app renders as a UML state diagram. You read code — you are not observing a running system.
+
+A state diagram captures ONE stateful lifecycle. If guidance names one, map that; otherwise pick the most central one in the product (an order/payment status, an approval/review state, a job/task lifecycle, an explicit XState/state-machine definition, a multi-step wizard).
+
+**States (nodes)** — each is `{ slug, name, kind, file?, description?, onEntry?, onExit?, activity? }`:
+
+- `kind`: `initial` (the start pseudostate — emit exactly one), `state` (a normal state), `final` (a terminal state), `choice` (a branch/decision pseudostate), `composite` (a state containing substates)
+- `onEntry` / `onExit` / `activity`: behaviours attached to the state, if the code has them
+- `name` is the human label (often the enum value, e.g. `PENDING`, `Shipped`)
+
+**Transitions (edges)** — each is `{ fromSlug, toSlug, kind: "transition", label?, sourceFile? }`:
+
+- `label` carries UML transition syntax: `trigger [guard] / action` — fill in whichever parts exist, e.g. `submit [isValid] / persist()`, `cancel`, `after(30d)`
+- `sourceFile` is where the transition is implemented (the `setStatus`, dispatch, or guard site)
+
+**Discipline**:
+
+- Be grounded — every state and transition MUST exist in the code (an enum value, a status write, a machine definition). No invented states.
+- Exactly one `initial`; wire it to the first real state. Include the `final` state(s) where the lifecycle ends.
+- Prefer one clear machine over a tangle. If several lifecycles exist, pick the most important and say so in the summary.
+
+**Process**:
+
+<!-- if:hasCodebase -->
+1. Detect the stack and search for status/state enums, state-machine libraries (XState, statecharts), `status`/`state` columns + the code that mutates them, or workflow/step definitions.
+2. Choose ONE lifecycle. Enumerate its states (enum members + start/terminal).
+3. For each place the state changes, read just enough to capture the trigger, guard, and action; emit a transition.
+4. Compose the summary (what this models, entry → exit).
+<!-- endif -->
+<!-- if:!hasCodebase -->
+5. Infer a reasonable lifecycle from the product description + guidance; say in the summary that it is inferred. Use concrete state names and transitions, no placeholders.
+<!-- endif -->

package/dist/workspace/session-workspace.d.ts

@@ -14,9 +14,9 @@
  * time, so follow-up turns are fast and always see the latest code.
  *
  * Repo resolution and the secure-token clone are shared with flow generation
- * (`phases/flow-shared/clone-repos.ts`).
+ * (`phases/diagram-shared/clone-repos.ts`).
  */
-import { type ClonedRepo } from '../phases/flow-shared/clone-repos.js';
+import { type ClonedRepo } from '../phases/diagram-shared/clone-repos.js';
 export interface SessionWorkspace {
     /** Directory holding every cloned repo as a subdirectory; the agent's cwd. */
     sessionDir: string;

package/dist/workspace/session-workspace.js

@@ -14,11 +14,11 @@
  * time, so follow-up turns are fast and always see the latest code.
  *
  * Repo resolution and the secure-token clone are shared with flow generation
- * (`phases/flow-shared/clone-repos.ts`).
+ * (`phases/diagram-shared/clone-repos.ts`).
  */
 import { mkdirSync } from 'fs';
 import { getGitHubConfigByProduct } from '../api/github.js';
-import { resolveTargetRepos, safeDirName, } from '../phases/flow-shared/clone-repos.js';
+import { resolveTargetRepos, safeDirName, } from '../phases/diagram-shared/clone-repos.js';
 import { logInfo, logWarning } from '../utils/logger.js';
 import { cloneIssueRepo, ensureWorkspaceDir, getIssueRepoPath, } from './workspace-manager.js';
 const SESSIONS_DIR_NAME = 'sessions';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edsger",
-  "version": "0.69.0",
+  "version": "0.71.0",
   "type": "module",
   "bin": {
     "edsger": "dist/index.js"