@tarcisiopgs/lisa 1.9.0 → 1.11.0

package/README.md

@@ -151,13 +151,13 @@ export JIRA_API_TOKEN=""       # Atlassian API token
 | `lisa run --once --dry-run` | **Recommended first step** — preview config without executing |
 | `lisa run --issue ID` | Process a specific issue by identifier or URL |
 | `lisa run --limit N` | Process up to N issues |
+| `lisa run --concurrency N` / `-c N` | Process up to N issues in parallel (default: 1) |
 | `lisa run --dry-run` | Preview without executing |
 | `lisa run --provider NAME` | Override AI provider |
 | `lisa run --source NAME` | Override issue source |
 | `lisa run --label NAME` | Override label filter |
 | `lisa run --github METHOD` | Override GitHub method (`cli` or `token`) |
-| `lisa run --json` | Output as JSON lines |
-| `lisa run --quiet` | Suppress non-essential output |
+| `lisa run --no-bell` | Disable terminal bell on issue completion/failure |
 | `lisa init` | Create `.lisa/config.yaml` interactively |
 | `lisa config` | Edit config interactively |
 | `lisa config --show` | Print current config as JSON |
@@ -182,7 +182,7 @@ When running in an interactive terminal, `lisa run` renders a real-time Kanban b
 └──────────────────────────┘ └───────────────────────────┘ └───────────────────────────┘
 ```
 
-In-progress cards show a live elapsed timer. When the loop is paused, the active card displays a visual pause indicator. The detail view includes a scroll bar when output overflows.
+In-progress cards show a live elapsed timer and the last action taken by the provider. A global progress bar in the header tracks overall session progress. When the loop is paused, active cards display a visual pause indicator. The detail view includes a scroll bar when output overflows and shows the active model name in the sidebar.
 
 ### Keyboard shortcuts
 
@@ -192,8 +192,11 @@ In-progress cards show a live elapsed timer. When the loop is paused, the active
 | `Tab` / `Shift+Tab` | Move between columns (alternative) |
 | `↑` / `↓` | Navigate cards / scroll output |
 | `Enter` | Open issue detail view (streams provider output) |
+| `o` | Open PR in browser (when viewing a completed card with a PR) |
 | `Esc` | Close detail view, return to board |
-| `p` | Pause / resume — loop finishes the current issue then waits |
+| `k` | Kill the selected in-progress issue |
+| `s` | Skip the selected in-progress issue |
+| `p` | Pause / resume all active providers |
 | `q` | Quit |
 
 The sidebar legend updates contextually: board shortcuts when browsing the Kanban, scroll and back hints when viewing issue detail. The terminal tab title also updates in real time: it shows a spinner with the active issue ID while work is in progress, and a checkmark when done.
@@ -231,16 +234,20 @@ repos:
 loop:
   cooldown: 10       # seconds between issues
   max_sessions: 0    # 0 = unlimited
+  concurrency: 1     # issues processed in parallel (default: 1; >1 forces worktree mode)
 
 logs:
   dir: .lisa/logs
-  format: text       # "text" or "json"
 
 # Optional — kill stuck providers
 overseer:
   enabled: true
   check_interval: 30     # seconds between git status checks
   stuck_threshold: 300   # seconds without git changes before killing
+
+# Optional — validate issue spec before accepting
+validation:
+  require_acceptance_criteria: true  # skip issues without detectable acceptance criteria (default: true)
 ```
 
 ### Source-Specific Fields
@@ -251,9 +258,18 @@ overseer:
 | `project` | Project name | — | Project identifier or UUID | — | — | — | — |
 | `pick_from` | Status to pick issues from | List to pick cards from | State name to pick issues from | Workflow state to pick stories from | — | — | Status to pick issues from |
 | `label` | Label to filter issues | Label to filter cards | Label to filter issues | Label to filter stories | Label to filter issues | Label to filter issues | Label to filter issues |
+| `remove_label` | Label removed after pickup (optional; defaults to `label`) | Same | Same | Same | Same | Same | Same |
 | `in_progress` | In-progress status | In-progress column | In-progress state name | In-progress workflow state | Label to apply on activate | Label to apply on activate | In-progress status name |
 | `done` | Destination status after PR | Destination column after PR | Done state name | Done workflow state | Closes the issue | Closes the issue | Destination status after PR |
 
+`label` can also be a list — Lisa picks any issue that has **all** of the specified labels. `remove_label` controls which label is removed after pickup, useful when you want to keep some labels intact. Example:
+
+```yaml
+source_config:
+  label: [ready, api]   # pick issues labelled both "ready" and "api"
+  remove_label: ready   # only remove "ready" after pickup; "api" is preserved
+```
+
 Plane example:
 
 ```yaml
@@ -320,28 +336,28 @@ source_config:
 
 **Multi-repo worktree** — When multiple repos are configured, Lisa runs a two-phase flow: a planning agent produces a `.lisa-plan.json` with ordered steps, then Lisa executes each step sequentially — one worktree and one PR per repo. Cross-repo context (branch names, PR URLs) is passed to each subsequent step.
 
-### Lifecycle Resources
+### Concurrent Execution
 
-For repos that need services running during implementation (databases, dev servers):
+Process multiple issues in parallel with `--concurrency`:
 
-```yaml
-repos:
-  - name: my-api
-    path: ./api
-    base_branch: main
-    lifecycle:
-      resources:
-        - name: postgres
-          check_port: 5432
-          up: "docker compose up -d postgres"
-          down: "docker compose down"
-          startup_timeout: 30
-      setup:
-        - "npx prisma generate"
-        - "npx prisma db push"
+```bash
+lisa run --concurrency 3   # or -c 3
 ```
 
-Lisa starts resources before the agent runs, waits for the port to be ready, runs setup commands, then stops everything after the session.
+Each issue runs in its own isolated worktree with an independent provider process. When `--concurrency` is greater than 1, worktree mode is enforced automatically. The default is 1 (sequential, backward-compatible).
+
+- **Isolation** — Each issue gets its own worktree, log file, and manifest. No shared state between concurrent sessions.
+- **Shared infrastructure** — Docker containers and lifecycle resources are started once and shared across worktrees.
+- **Guardrails** — Writes to the guardrails file are serialized to prevent concurrent corruption.
+- **TUI** — Multiple cards appear in the In Progress column simultaneously. `[k]` and `[s]` target the selected card; `[p]` pauses all active providers.
+- **Fallback** — Each issue has its own independent fallback chain.
+- **Slot filling** — When an issue completes, the freed slot is immediately filled with the next available issue.
+
+### PR Stacking
+
+When an issue depends on another issue that is still in progress, Lisa passes the dependency context to the agent automatically. The agent receives the parent issue ID, the branch name, the open PR URL, and the list of changed files — so it can build on top of the parent branch cleanly rather than branching from `main`.
+
+Lisa detects blocked issues using the `completedBlockerIds` from your issue tracker (Linear blockers, GitHub milestone links, etc.) and skips issues whose blockers are not yet completed. Once a blocker is resolved, the dependent issue becomes eligible and will be picked up in a future loop.
 
 ### Recovery Mechanisms
 
@@ -354,6 +370,48 @@ Lisa starts resources before the agent runs, waits for the port to be ready, run
 
 When enabled, the overseer periodically checks `git status` in the working directory. If no changes are detected within `stuck_threshold` seconds, the provider process is killed and the error is eligible for fallback to the next model.
 
+### Issue Spec Validation
+
+Before starting work on an issue, Lisa validates that it has a minimum spec. Issues that fail validation are skipped, labelled `needs-spec`, and have their `ready` label removed — so they never block the queue.
+
+An issue passes validation if its description is non-empty and contains at least one of:
+
+- A Markdown checklist item (`- [ ]`)
+- The phrase `acceptance criteria` or `critérios`
+- The words `expected`, `should`, or `deve`
+
+To disable spec validation (e.g. for quick one-off issues):
+
+```yaml
+validation:
+  require_acceptance_criteria: false
+```
+
+> **Note:** The `needs-spec` label must exist in your issue tracker before Lisa can apply it. Create it manually if it does not exist — Lisa will log a warning if the label is missing.
+
+### Infrastructure Auto-Discovery
+
+Lisa auto-discovers Docker Compose services in each repository and starts them before handing control to the agent. If a `docker-compose.yml` / `compose.yml` is present, Lisa reads port mappings and starts the services, waiting for each port to become ready.
+
+**Dynamic port allocation** prevents collisions when multiple Lisa instances run in parallel. Add `port_range` and `port_env_var` to any discovered or manually configured resource:
+
+```yaml
+repos:
+  - path: api
+    # lifecycle config is resolved by auto-discovery (docker-compose.yml)
+    # port_range and port_env_var can be set via manual config override
+```
+
+When `port_range` is set, Lisa scans ports `check_port` through `check_port + port_range - 1` and picks the first free one. The chosen port is injected into the resource process via `port_env_var` and is available to `setup` commands and the agent environment.
+
+| Field | Type | Description |
+|---|---|---|
+| `check_port` | `number` | Preferred (base) port |
+| `port_range` | `number` (optional) | How many ports to scan from `check_port` |
+| `port_env_var` | `string` (optional) | Env var name to inject the allocated port (e.g. `DATABASE_PORT`) |
+
+If no free port is found within the range, Lisa logs a clear error and aborts the session.
+
 ### Auto-Detection
 
 Lisa auto-detects `vitest` or `jest` from `package.json` dependencies and injects the correct test command into the agent prompt. It also detects the package manager from lockfiles (`bun.lockb`/`bun.lock` → `bun`, `pnpm-lock.yaml` → `pnpm`, `yarn.lock` → `yarn`, otherwise `npm`).

package/dist/{chunk-QQBOYEWI.js → chunk-H6W3UZ3N.js}

@@ -35,9 +35,9 @@ function stopSpinner(message) {
     writeOSC(message);
   }
 }
-function notify() {
+function notify(count = 1) {
   if (!isTTY()) return;
-  process.stdout.write("\x07");
+  process.stdout.write("\x07".repeat(count));
 }
 function resetTitle() {
   if (!isTTY()) return;
@@ -50,12 +50,28 @@ import { useEffect, useState } from "react";
 var KanbanEmitter = class extends EventEmitter {
 };
 var kanbanEmitter = new KanbanEmitter();
-function useKanbanState() {
+function registerBellListeners(bellEnabled) {
+  if (!bellEnabled) return () => {
+  };
+  const onDone = () => notify(1);
+  const onReverted = () => notify(2);
+  const onComplete = () => notify(1);
+  kanbanEmitter.on("issue:done", onDone);
+  kanbanEmitter.on("issue:reverted", onReverted);
+  kanbanEmitter.on("work:complete", onComplete);
+  return () => {
+    kanbanEmitter.off("issue:done", onDone);
+    kanbanEmitter.off("issue:reverted", onReverted);
+    kanbanEmitter.off("work:complete", onComplete);
+  };
+}
+function useKanbanState(bellEnabled) {
   const [cards, setCards] = useState([]);
   const [isEmpty, setIsEmpty] = useState(false);
   const [workComplete, setWorkComplete] = useState(
     null
   );
+  const [modelInUse, setModelInUse] = useState(null);
   useEffect(() => {
     const onQueued = (issue) => {
       setCards((prev) => {
@@ -121,15 +137,20 @@ function useKanbanState() {
         )
       );
     };
-    const onProviderPaused = () => {
+    const onProviderPaused = (issueId) => {
       setCards(
-        (prev) => prev.map((c) => c.column === "in_progress" ? { ...c, pausedAt: Date.now() } : c)
+        (prev) => prev.map((c) => {
+          if (c.column !== "in_progress") return c;
+          if (issueId && c.id !== issueId) return c;
+          return { ...c, pausedAt: Date.now() };
+        })
       );
     };
-    const onProviderResumed = () => {
+    const onProviderResumed = (issueId) => {
       setCards(
         (prev) => prev.map((c) => {
           if (c.column !== "in_progress" || !c.pausedAt) return c;
+          if (issueId && c.id !== issueId) return c;
           const pauseDuration = Date.now() - c.pausedAt;
           return {
             ...c,
@@ -153,10 +174,13 @@ function useKanbanState() {
     kanbanEmitter.on("provider:paused", onProviderPaused);
     kanbanEmitter.on("provider:resumed", onProviderResumed);
     kanbanEmitter.on("issue:output", onOutput);
+    const onModelChanged = (model) => setModelInUse(model);
+    kanbanEmitter.on("provider:model-changed", onModelChanged);
     const onEmpty = () => setIsEmpty(true);
     const onComplete = (data) => setWorkComplete(data);
     kanbanEmitter.on("work:empty", onEmpty);
     kanbanEmitter.on("work:complete", onComplete);
+    const cleanupBell = registerBellListeners(bellEnabled);
     return () => {
       kanbanEmitter.off("issue:queued", onQueued);
       kanbanEmitter.off("issue:started", onStarted);
@@ -167,11 +191,13 @@ function useKanbanState() {
       kanbanEmitter.off("provider:paused", onProviderPaused);
       kanbanEmitter.off("provider:resumed", onProviderResumed);
       kanbanEmitter.off("issue:output", onOutput);
+      kanbanEmitter.off("provider:model-changed", onModelChanged);
       kanbanEmitter.off("work:empty", onEmpty);
       kanbanEmitter.off("work:complete", onComplete);
+      cleanupBell();
     };
-  }, []);
-  return { cards, isEmpty, workComplete };
+  }, [bellEnabled]);
+  return { cards, isEmpty, workComplete, modelInUse };
 }
 
 export {