@tarcisiopgs/lisa 1.18.1 → 1.19.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,18 +1,15 @@
1
1
  # Lisa
2
2
 
3
3
  <p align="center">
4
- <strong>Label an issue. Walk away. Come back to a PR.</strong>
4
+ <img src="assets/demo.gif" alt="Lisa demo" />
5
5
  </p>
6
6
 
7
7
  <p align="center">
8
- <a href="https://www.npmjs.com/package/@tarcisiopgs/lisa"><img src="https://img.shields.io/npm/v/@tarcisiopgs/lisa.svg" alt="npm version" /></a>
9
- <a href="https://www.npmjs.com/package/@tarcisiopgs/lisa"><img src="https://img.shields.io/npm/dm/@tarcisiopgs/lisa.svg" alt="npm downloads" /></a>
10
- <a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-blue.svg" alt="License: MIT" /></a>
11
- <img src="https://img.shields.io/node/v/%40tarcisiopgs%2Flisa" alt="Node.js version" />
8
+ <strong>Label an issue. Walk away. Come back to a PR.</strong>
12
9
  </p>
13
10
 
14
11
  <p align="center">
15
- <img src="assets/demo.gif?v=2" alt="Lisa demo" width="800" />
12
+ Lisa is an autonomous issue resolver that turns your backlog into pull requests — no babysitting required.
16
13
  </p>
17
14
 
18
15
  ---
@@ -21,46 +18,61 @@
21
18
 
22
19
  ```bash
23
20
  npm install -g @tarcisiopgs/lisa
24
- lisa init # interactive setup — picks your source + provider
25
- lisa run # start resolving issues
21
+ lisa init
22
+ lisa run
26
23
  ```
27
24
 
28
- Verify your setup first with `lisa run --once --dry-run` no issues will be fetched, no code written, no PRs created.
25
+ That's it. Lisa picks up the next labeled issue, implements it, pushes a branch, opens a pull request, and moves the ticket to "In Review" — all without you touching it.
29
26
 
30
- Lisa picks up the next labeled issue, implements it, pushes a branch, opens a pull request, and moves the ticket to "In Review" — all without you touching it.
27
+ ## Try it safely first
31
28
 
32
- ---
29
+ Before letting Lisa touch real issues, verify your configuration with `--dry-run`. No issues will be fetched, no code will be written, no PRs will be created.
30
+
31
+ ```bash
32
+ lisa run --once --dry-run
33
+ ```
33
34
 
34
- ## How It Works
35
+ Example output:
35
36
 
36
37
  ```
37
- ┌─────────┐ ┌──────────┐ ┌───────────┐ ┌──────────┐ ┌────┐ ┌────────┐
38
- │ Fetch │───▶│ Activate │───▶│ Implement │───▶│ Validate │───▶│ PR │───▶│ Update │
39
- └─────────┘ └──────────┘ └───────────┘ └──────────┘ └────┘ └────────┘
38
+ [dry-run] Would fetch issue from linear (Engineering/Web App)
39
+ [dry-run] Workflow mode: worktree
40
+ [dry-run] Models priority: claude/claude-sonnet-4-6
41
+ [dry-run] Then implement, push, create PR, and update issue status
40
42
  ```
41
43
 
42
- 1. **Fetch and activate** — Pulls the next priority-sorted issue matching your configured label and moves it to `in_progress`.
43
- 2. **Implement** — Builds a structured prompt with full issue context and sends it to the AI agent. The agent works in a worktree or branch, implements the change, runs tests, and commits.
44
- 3. **Push and PR** — Pushes the branch, creates a pull request referencing the original issue. If pre-push hooks fail, re-invokes the agent with the error output and retries.
45
- 4. **Update and loop** — Moves the issue to `done`, removes the pickup label, and picks the next issue. Stops when the queue is empty.
44
+ If the output looks correct, you're ready to run Lisa for real.
46
45
 
47
- ---
46
+ ## What Lisa Does
47
+
48
+ Lisa follows a deterministic pipeline:
48
49
 
49
- ## Issue Sources
50
+ ```
51
+ ┌─────────┐ ┌──────────┐ ┌─────────┐ ┌───────────┐ ┌──────────┐ ┌────┐ ┌────────┐
52
+ │ Fetch │───▶│ Activate │───▶│ Context │───▶│ Implement │───▶│ Validate │───▶│ PR │───▶│ Update │
53
+ └─────────┘ └──────────┘ └─────────┘ └───────────┘ └──────────┘ └────┘ └────────┘
54
+ ```
50
55
 
51
- | Source | Key |
52
- |--------|-----|
53
- | Linear | `linear` |
54
- | GitHub Issues | `github-issues` |
55
- | Jira | `jira` |
56
- | GitLab Issues | `gitlab-issues` |
57
- | Trello | `trello` |
58
- | Plane | `plane` |
59
- | Shortcut | `shortcut` |
56
+ 1. **Fetch** Pulls the next issue from Linear, Trello, Plane, Shortcut, GitLab Issues, GitHub Issues, or Jira matching the configured label, team, and project. Issues are sorted by priority. Blocked issues are skipped.
57
+ 2. **Activate** — Moves the issue to `in_progress` so your team knows it's being worked on.
58
+ 3. **Context** On first run, Lisa analyzes your codebase and generates `.lisa/context.md` — a concise project guide (stack, conventions, constraints) injected into every agent prompt. Skipped automatically if the file already exists.
59
+ 4. **Implement** Builds a structured prompt with full issue context and sends it to the AI agent. The agent works in a worktree or branch, implements the change, runs tests, and commits.
60
+ 5. **Validate** If the agent's tests pass and pre-push hooks succeed, the branch is pushed. If hooks fail, Lisa re-invokes the agent with the error output and retries.
61
+ 6. **PR** Pushes the branch and creates a pull request referencing the original issue.
62
+ 7. **Update** Moves the issue to the `done` status and removes the pickup label.
63
+ 8. **Next** Picks the next issue. When there are no more matching issues, Lisa stops.
60
64
 
61
- ---
65
+ ### What makes it different
66
+
67
+ - **Deterministic, not hopeful** — Each issue follows a structured pipeline with clear stages. No blind retries, no speculative loops.
68
+ - **Token efficiency** — Each issue gets one focused prompt. No wasted retries, no idle polling.
69
+ - **Multi-repo awareness** — Plans across multiple repos, executes in the correct order, creates one PR per repo.
70
+ - **Model fallback** — Configure a chain of models. Transient errors (429, quota, timeout) trigger the next model automatically.
71
+ - **Workflow integration** — Issues move through your board in real time. Your team always knows what's being worked on.
72
+ - **Self-healing** — Orphan issues stuck in "In Progress" are recovered on startup. Pre-push failures trigger the agent to fix and retry.
73
+ - **Guardrails** — Past failures are logged and injected into future prompts so the agent avoids repeating mistakes.
62
74
 
63
- ## AI Providers
75
+ ## Providers
64
76
 
65
77
  | Provider | Key | Command |
66
78
  |----------|-----|---------|
@@ -77,7 +89,7 @@ At least one provider must be installed and available in your PATH.
77
89
 
78
90
  ### Fallback Chain
79
91
 
80
- Configure multiple models — Lisa tries each in order. Transient errors (429, quota, timeout, network) trigger the next model automatically.
92
+ Configure multiple models — Lisa tries each in order. Transient errors (429, quota, timeout, network) trigger the next model; non-transient errors stop the chain.
81
93
 
82
94
  ```yaml
83
95
  provider: claude
@@ -87,69 +99,166 @@ models:
87
99
  - claude-haiku-4-5 # fallback 2
88
100
  ```
89
101
 
90
- ---
91
-
92
- ## PR Platforms
102
+ When the TUI is active, the sidebar shows a **Model Queue** — the currently active model is highlighted with a bullet (●).
93
103
 
94
- | Platform | Key | Auth |
95
- |----------|-----|------|
96
- | GitHub CLI | `cli` | `gh auth login` |
97
- | GitHub API | `token` | `GITHUB_TOKEN` |
98
- | GitLab | `gitlab` | `GITLAB_TOKEN` |
99
- | Bitbucket | `bitbucket` | `BITBUCKET_TOKEN` + `BITBUCKET_USERNAME` |
104
+ ## Install
100
105
 
101
- ---
106
+ ```bash
107
+ npm install -g @tarcisiopgs/lisa
108
+ ```
102
109
 
103
110
  ## Environment Variables
104
111
 
105
- Set the tokens for your chosen source and PR platform:
106
-
107
112
  ```bash
108
- # PR platform
109
- GITHUB_TOKEN # GitHub (platform: cli or token)
110
- GITLAB_TOKEN # GitLab (platform: gitlab)
111
- BITBUCKET_TOKEN # Bitbucket app password (platform: bitbucket)
112
- BITBUCKET_USERNAME # Bitbucket username
113
-
114
- # Issue sources
115
- LINEAR_API_KEY # source: linear
116
- TRELLO_API_KEY # source: trello
117
- TRELLO_TOKEN
118
- SHORTCUT_API_TOKEN # source: shortcut
119
- PLANE_API_TOKEN # source: plane
120
- PLANE_BASE_URL # optional, defaults to https://api.plane.so
121
- GITLAB_TOKEN # source: gitlab-issues
122
- GITLAB_BASE_URL # optional, defaults to https://gitlab.com
123
- GITHUB_TOKEN # source: github-issues
124
- JIRA_BASE_URL # source: jira (e.g. https://yourorg.atlassian.net)
125
- JIRA_EMAIL
126
- JIRA_API_TOKEN # generate at id.atlassian.com — expires, regenerate if 401
127
-
128
- # Aider provider (one of)
129
- GEMINI_API_KEY
130
- OPENAI_API_KEY
131
- ANTHROPIC_API_KEY
113
+ # Required for PR creation (at least one)
114
+ export GITHUB_TOKEN="" # or have `gh` CLI authenticated
115
+ export GITLAB_TOKEN="" # platform: gitlab
116
+ export BITBUCKET_TOKEN="" # platform: bitbucket
117
+ export BITBUCKET_USERNAME=""
118
+
119
+ # Required when source = linear
120
+ export LINEAR_API_KEY=""
121
+
122
+ # Required when source = trello
123
+ export TRELLO_API_KEY=""
124
+ export TRELLO_TOKEN=""
125
+
126
+ # Required when source = plane
127
+ export PLANE_API_TOKEN=""
128
+ export PLANE_BASE_URL="" # optional; defaults to https://api.plane.so
129
+
130
+ # Required when source = shortcut
131
+ export SHORTCUT_API_TOKEN=""
132
+
133
+ # Required when source = gitlab-issues
134
+ export GITLAB_TOKEN=""
135
+ export GITLAB_BASE_URL="" # optional; defaults to https://gitlab.com
136
+
137
+ # Required when source = github-issues
138
+ export GITHUB_TOKEN="" # same token used for PR creation
139
+
140
+ # Required when source = jira
141
+ export JIRA_BASE_URL="" # e.g. https://yourcompany.atlassian.net
142
+ export JIRA_EMAIL="" # Atlassian account email
143
+ export JIRA_API_TOKEN="" # Atlassian API token
144
+
145
+ # Required when provider = aider (one of)
146
+ export GEMINI_API_KEY=""
147
+ export OPENAI_API_KEY=""
148
+ export ANTHROPIC_API_KEY=""
132
149
  ```
133
150
 
134
- ---
135
-
136
151
  ## Commands
137
152
 
138
153
  | Command | Description |
139
154
  |---------|-------------|
140
155
  | `lisa run` | Run the agent loop |
141
156
  | `lisa run --once` | Process a single issue |
142
- | `lisa run --once --dry-run` | Preview config without executing |
143
- | `lisa run --watch` | Poll for new issues every 60s after queue empties |
157
+ | `lisa run --once --dry-run` | **Recommended first step** — preview config without executing |
158
+ | `lisa run --watch` | Keep running after queue empties — poll for new issues every 60s |
144
159
  | `lisa run --issue ID` | Process a specific issue by identifier or URL |
145
160
  | `lisa run --concurrency N` | Process N issues in parallel (each in its own worktree) |
161
+ | `lisa run --limit N` | Stop after processing N issues |
162
+ | `lisa run --provider NAME` | Override AI provider |
163
+ | `lisa run --source NAME` | Override issue source |
164
+ | `lisa run --label NAME` | Override label filter |
165
+ | `lisa run --platform NAME` | Override PR platform (`cli`, `token`, `gitlab`, `bitbucket`) |
166
+ | `lisa run --no-bell` | Disable terminal bell on completion/failure |
167
+ | `lisa run --demo` | Run an animated demo of the Kanban UI with fake issues |
146
168
  | `lisa init` | Create `.lisa/config.yaml` interactively |
147
169
  | `lisa config --show` | Print current config |
148
- | `lisa status` | Show session stats |
170
+ | `lisa status` | Show session stats and log file location |
171
+ | `lisa context` | Show the current `.lisa/context.md` for all repos |
172
+ | `lisa context refresh` | Regenerate `.lisa/context.md` |
173
+ | `lisa context refresh --repo NAME` | Regenerate context for a specific repo (multi-repo only) |
174
+ | `lisa feedback --pr URL` | Inject PR review feedback from a closed PR into guardrails |
149
175
 
150
- Run `lisa run --help` for all available flags.
176
+ ## TUI
151
177
 
152
- ---
178
+ When running in an interactive terminal, `lisa run` renders a real-time Kanban board:
179
+
180
+ ```
181
+ ┌──────────────────────────┐ ┌───────────────────────────┐ ┌───────────────────────────┐
182
+ │ ▶ BACKLOG [3] │ │ ▶ IN PROGRESS [1] │ │ ▶ IN REVIEW [2] │
183
+ │ │ │ │ │ │
184
+ │ ┌────────────────────┐ │ │ ┌─────────────────────┐ │ │ ┌─────────────────────┐ │
185
+ │ │ ENG-42 │ │ │ │ ● ENG-38 │ │ │ │ ✓ ENG-35 │ │
186
+ │ │ Add dark mode │ │ │ │ Fix login redirect │ │ │ │ Update dependencies │ │
187
+ │ │ ready │ │ │ │ ~1m running │ │ │ │ PR created │ │
188
+ │ └────────────────────┘ │ │ └─────────────────────┘ │ │ └─────────────────────┘ │
189
+ └──────────────────────────┘ └───────────────────────────┘ └───────────────────────────┘
190
+ ```
191
+
192
+ ### Keyboard shortcuts
193
+
194
+ | Key | Action |
195
+ |-----|--------|
196
+ | `←` `→` | Switch columns |
197
+ | `↑` `↓` | Navigate cards within a column |
198
+ | `↵` | Open issue detail view (streams provider output) |
199
+ | `p` | Pause / resume (suspends the active provider process) |
200
+ | `k` | Kill the selected in-progress issue (marks it for retry) |
201
+ | `s` | Skip the selected in-progress issue (moves back to Backlog) |
202
+ | `q` | Quit |
203
+ | `Esc` | Return to board from detail view |
204
+ | `o` | Open PR URL in browser (detail view, when PR exists) |
205
+
206
+ The terminal tab title updates in real time: it shows a spinner with the active issue ID while work is in progress, and a checkmark when done.
207
+
208
+ ### State Persistence
209
+
210
+ The Kanban board state is saved automatically to the OS cache directory and restored when you restart `lisa run`. Cards survive process restarts — issues that completed remain visible in "Done", and issues that were mid-flight are correctly re-queued as Backlog.
211
+
212
+ ### PR Merge Detection
213
+
214
+ For GitHub and GitLab PRs, Lisa polls every 60 seconds and marks cards in the Done column as **merged** once the PR is merged — live, without restarting.
215
+
216
+ ## Project Context
217
+
218
+ On first run, Lisa automatically analyzes your codebase and writes `.lisa/context.md` — a concise document covering your stack, exact tool commands, file conventions, and constraints. This file is injected into every agent prompt so the agent works correctly from the start without rediscovering project-specific patterns.
219
+
220
+ Context is generated once and reused on subsequent runs. To regenerate it (e.g. after switching stacks or adding tooling):
221
+
222
+ ```bash
223
+ lisa context refresh
224
+ ```
225
+
226
+ For multi-repo workspaces, Lisa generates a per-repo `context.md` for each repository plus a global workspace context describing cross-repo relationships and execution ordering rules.
227
+
228
+ ```bash
229
+ lisa context refresh --repo my-api # regenerate a single repo's context
230
+ ```
231
+
232
+ If context generation fails, Lisa logs a warning and continues — it is never a blocker.
233
+
234
+ ## Writing Issues
235
+
236
+ Issue quality is the single biggest factor in PR quality. Lisa validates issues before accepting them — vague tickets without clear criteria are skipped and labelled `needs-spec`.
237
+
238
+ Issues must contain acceptance criteria: markdown checklists (`- [ ]`) or keywords like `acceptance criteria`, `expected`, `should`.
239
+
240
+ ### Example
241
+
242
+ ```markdown
243
+ Title: Add rate limiting to /api/users endpoint
244
+
245
+ Description:
246
+ Implement rate limiting on the `/api/users` endpoint to prevent abuse.
247
+
248
+ Relevant files:
249
+ - src/routes/users.ts
250
+ - src/middleware/auth.ts
251
+
252
+ Acceptance criteria:
253
+ - [ ] Requests exceeding 100/min per IP return HTTP 429
254
+ - [ ] Rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining) included in all responses
255
+ - [ ] Rate limit state stored in Redis (use existing connection from src/lib/redis.ts)
256
+ - [ ] Existing tests still pass
257
+
258
+ Stack: Express, Redis
259
+ ```
260
+
261
+ Including **relevant files**, **technical constraints**, and **stack information** in the description leads to better results.
153
262
 
154
263
  ## Configuration
155
264
 
@@ -158,7 +267,7 @@ Config lives in `.lisa/config.yaml`. Run `lisa init` to create it interactively.
158
267
  ```yaml
159
268
  provider: claude
160
269
  source: linear
161
- workflow: worktree # "worktree" (isolated) or "branch" (in-place)
270
+ workflow: worktree
162
271
 
163
272
  source_config:
164
273
  team: Engineering
@@ -168,110 +277,156 @@ source_config:
168
277
  in_progress: In Progress
169
278
  done: In Review
170
279
 
171
- platform: cli # "cli", "token", "gitlab", or "bitbucket"
280
+ platform: cli # "cli" (gh), "token" (GITHUB_TOKEN), "gitlab", or "bitbucket"
172
281
  workspace: .
173
282
  base_branch: main
174
283
 
175
- # Multi-repo (optional)
176
284
  repos:
177
285
  - name: my-api
178
286
  path: ./api
179
287
  base_branch: main
180
- match: "[API]" # route issues by title prefix
288
+ match: "[API]" # route issues whose title starts with "[API]" to this repo
181
289
  - name: my-app
182
290
  path: ./app
183
291
  base_branch: main
184
292
 
185
293
  loop:
186
- cooldown: 10 # seconds between issues
187
- max_sessions: 0 # 0 = unlimited
188
- session_timeout: 0 # seconds per provider run (0 = disabled)
294
+ cooldown: 10 # seconds between issues
295
+ max_sessions: 0 # 0 = unlimited
296
+ session_timeout: 0 # seconds per provider run (0 = disabled)
189
297
 
190
298
  # Optional — kill stuck providers
191
299
  overseer:
192
300
  enabled: true
193
- check_interval: 30 # seconds between git status checks
194
- stuck_threshold: 300 # seconds without changes before killing
301
+ check_interval: 30 # seconds between git status checks
302
+ stuck_threshold: 300 # seconds without git changes before killing
195
303
 
196
304
  # Optional — Docker infrastructure management (disabled by default)
197
305
  lifecycle:
198
- mode: auto # "auto" = start/stop services, "skip" = disabled (default), "validate-only" = fail if not running
199
- timeout: 30 # seconds per service to wait on startup
306
+ mode: auto # "auto" = start/stop services, "skip" = disabled (default), "validate-only" = fail if not running
307
+ timeout: 30 # seconds per service to wait on startup
200
308
 
201
309
  # Optional — skip issues without acceptance criteria
202
310
  validation:
203
311
  require_acceptance_criteria: true
204
312
  ```
205
313
 
206
- ### Source-specific notes
207
-
208
- **GitHub Issues / GitLab Issues** — `pick_from`, `in_progress`, and `done` are **labels**, not statuses. Make sure `in_progress` differs from `pick_from`; using the same value causes Lisa to re-pick issues that are already being worked on.
209
-
210
- **Trello** — `team`, `pick_from`, `in_progress`, and `done` are list **names** (not IDs).
211
-
212
- **Jira** — `team` is your project **key** (e.g. `ENG`). `JIRA_API_TOKEN` is generated at [id.atlassian.com](https://id.atlassian.com) and expires — regenerate if you get 401 errors.
314
+ ### Source-Specific Fields
213
315
 
214
- **Goose** `lisa init` asks which backend to use (gemini-cli, anthropic, openai, etc.) and saves it to config. No env vars needed. You can also set `GOOSE_PROVIDER` manually — it takes precedence over the config value.
316
+ | Field | Linear | Trello | Plane | Shortcut | GitLab Issues | GitHub Issues | Jira |
317
+ |-------|--------|--------|-------|----------|---------------|---------------|------|
318
+ | `team` | Team name | Board name | Workspace slug | Group name (optional) | Project path (`namespace/project`) or numeric ID | `owner/repo` | Project key (e.g. `ENG`) |
319
+ | `project` | Project name | — | Project identifier or UUID | — | — | — | — |
320
+ | `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 |
321
+ | `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 |
322
+ | `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 |
323
+ | `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 |
215
324
 
216
- **Aider** — requires a direct LLM API key (`GEMINI_API_KEY`, `OPENAI_API_KEY`, or `ANTHROPIC_API_KEY`). Does not support OAuth or cached credentials.
325
+ Plane example:
217
326
 
218
- **OpenCode** — if `~/.config/opencode/config.json` contains MCP entries, remove them or set the file to `{}` to prevent OpenCode from hanging on startup.
219
-
220
- ---
327
+ ```yaml
328
+ source: plane
329
+ source_config:
330
+ team: my-workspace # workspace slug (or set PLANE_WORKSPACE env var)
331
+ project: DEV # project identifier or UUID
332
+ label: ready # issues with this label are picked up
333
+ pick_from: Todo # state to fetch issues from
334
+ in_progress: In Progress # state set when Lisa starts working
335
+ done: Done # state set after PR is created
336
+ ```
221
337
 
222
- ### Workflow Modes
338
+ Shortcut example:
223
339
 
224
- **Branch** — The agent creates a branch in your current checkout. Simple setup, works everywhere.
340
+ ```yaml
341
+ source: shortcut
342
+ source_config:
343
+ label: ready # stories with this label are picked up
344
+ pick_from: Ready for Development # workflow state to fetch stories from
345
+ in_progress: In Progress # state set when Lisa starts working
346
+ done: Done # state set after PR is created
347
+ ```
225
348
 
226
- **Worktree** Lisa creates an isolated git worktree per issue under `.worktrees/`. Your main checkout stays untouched. Cleaned up automatically after the PR is created.
349
+ GitLab Issues example:
227
350
 
228
- When `--concurrency` is greater than 1, worktree mode is enforced automatically.
351
+ ```yaml
352
+ source: gitlab-issues
353
+ source_config:
354
+ team: my-org/my-repo # namespace/project path or numeric project ID
355
+ label: ready # issues with this label are picked up
356
+ in_progress: in-progress # label applied when Lisa starts working
357
+ done: "" # issue is closed after PR (value unused)
358
+ ```
229
359
 
230
- ---
360
+ GitHub Issues example:
231
361
 
232
- ### Session Timeout
362
+ ```yaml
363
+ source: github-issues
364
+ source_config:
365
+ team: my-org/my-repo # owner/repo
366
+ label: ready # issues with this label are picked up
367
+ in_progress: in-progress # label applied when Lisa starts working
368
+ done: "" # issue is closed after PR (value unused)
369
+ ```
233
370
 
234
- If a provider hangs (e.g. misconfigured model, network issue), Lisa can kill it after a configurable duration:
371
+ Jira example:
235
372
 
236
373
  ```yaml
237
- loop:
238
- session_timeout: 300 # kill provider after 5 minutes (0 = disabled, default)
374
+ source: jira
375
+ source_config:
376
+ team: ENG # Jira project key
377
+ label: lisa # label to filter issues
378
+ pick_from: Backlog # status to pick issues from
379
+ in_progress: In Progress # status applied when Lisa starts working
380
+ done: In Review # status applied after PR is created
239
381
  ```
240
382
 
241
- When the timeout fires, the provider process is killed and the error is eligible for fallback — Lisa will try the next model in your chain. This is disabled by default so long-running sessions work uninterrupted.
383
+ ### Workflow Modes
242
384
 
243
- ---
385
+ **Branch** — The AI agent creates a branch directly in your current checkout, implements the changes, and pushes. Simple setup, works everywhere.
244
386
 
245
- ## Writing Issues
387
+ **Worktree** Lisa creates an isolated [git worktree](https://git-scm.com/docs/git-worktree) for each issue under `.worktrees/`. The agent works in the worktree without touching your main checkout. After the PR is created, the worktree is cleaned up automatically. Ideal when you want to keep working in the repo while Lisa resolves issues in the background.
246
388
 
247
- Issue quality is the single biggest factor in PR quality. Lisa validates issues before accepting them vague tickets without clear criteria are skipped and labelled `needs-spec`.
389
+ **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 sequentiallyone worktree and one PR per repo. Cross-repo context (branch names, PR URLs) is passed to each subsequent step.
248
390
 
249
- Issues must contain acceptance criteria: markdown checklists (`- [ ]`) or keywords like `acceptance criteria`, `expected`, `should`.
391
+ When `--concurrency` is greater than 1, worktree mode is enforced automatically.
250
392
 
251
- ### Example
393
+ ### Lifecycle Resources
252
394
 
253
- ```markdown
254
- Title: Add rate limiting to /api/users endpoint
395
+ For repos that need services running during implementation (databases, dev servers):
255
396
 
256
- Description:
257
- Implement rate limiting on the `/api/users` endpoint to prevent abuse.
397
+ ```yaml
398
+ repos:
399
+ - name: my-api
400
+ path: ./api
401
+ base_branch: main
402
+ lifecycle:
403
+ resources:
404
+ - name: postgres
405
+ check_port: 5432
406
+ up: "docker compose up -d postgres"
407
+ down: "docker compose down"
408
+ startup_timeout: 30
409
+ setup:
410
+ - "npx prisma generate"
411
+ - "npx prisma db push"
412
+ ```
258
413
 
259
- Relevant files:
260
- - src/routes/users.ts
261
- - src/middleware/auth.ts
414
+ Lisa starts resources before the agent runs, waits for the port to be ready, runs setup commands, then stops everything after the session.
262
415
 
263
- Acceptance criteria:
264
- - [ ] Requests exceeding 100/min per IP return HTTP 429
265
- - [ ] Rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining) included in all responses
266
- - [ ] Rate limit state stored in Redis (use existing connection from src/lib/redis.ts)
267
- - [ ] Existing tests still pass
416
+ ### Recovery Mechanisms
268
417
 
269
- Stack: Express, Redis
270
- ```
418
+ - **Orphan recovery** — On startup, Lisa scans for issues stuck in `in_progress` from interrupted runs and reverts them to `pick_from`.
419
+ - **Push recovery** — If `git push` fails due to pre-push hooks (linter, typecheck, tests), Lisa re-invokes the agent with the error output and retries the push.
420
+ - **Signal handling** — SIGINT/SIGTERM gracefully revert the active issue to its previous status before exiting.
421
+ - **Guardrails** — Failed sessions are logged and injected into future prompts so the agent avoids repeating the same mistakes. Use `lisa feedback --pr URL` to manually inject review feedback from a closed PR.
271
422
 
272
- Including **relevant files**, **technical constraints**, and **stack information** in the description leads to better results.
423
+ ### Overseer
273
424
 
274
- ---
425
+ 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.
426
+
427
+ ### Auto-Detection
428
+
429
+ 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`).
275
430
 
276
431
  ## License
277
432
 
@@ -647,8 +647,8 @@ function registerBellListeners(bellEnabled) {
647
647
  kanbanEmitter.off("work:complete", onComplete);
648
648
  };
649
649
  }
650
- function useKanbanState(bellEnabled) {
651
- const [cards, setCards] = useState([]);
650
+ function useKanbanState(bellEnabled, initialCards = []) {
651
+ const [cards, setCards] = useState(initialCards);
652
652
  const [isEmpty, setIsEmpty] = useState(false);
653
653
  const [isWatching, setIsWatching] = useState(false);
654
654
  const [isWatchPrompt, setIsWatchPrompt] = useState(false);
@@ -816,6 +816,15 @@ function useKanbanState(bellEnabled) {
816
816
  }
817
817
  };
818
818
  }, [bellEnabled]);
819
+ useEffect(() => {
820
+ for (const card of initialCards) {
821
+ if (card.column === "done" && card.prUrls.length > 0 && !card.merged) {
822
+ for (const url of card.prUrls) {
823
+ startMergePolling(card.id, url);
824
+ }
825
+ }
826
+ }
827
+ }, []);
819
828
  return { cards, isEmpty, isWatching, isWatchPrompt, workComplete, modelInUse };
820
829
  }
821
830
 
@@ -44,6 +44,9 @@ function getPlanPath(cwd, issueId) {
44
44
  }
45
45
  return join(getCacheDir(cwd), "plan.json");
46
46
  }
47
+ function getKanbanStatePath(cwd) {
48
+ return join(getCacheDir(cwd), "kanban-state.json");
49
+ }
47
50
  function ensureCacheDir(cwd) {
48
51
  const dir = getCacheDir(cwd);
49
52
  if (!existsSync(dir)) {
@@ -76,6 +79,7 @@ export {
76
79
  getManifestPath,
77
80
  getPrCachePath,
78
81
  getPlanPath,
82
+ getKanbanStatePath,
79
83
  ensureCacheDir,
80
84
  rotateLogFiles
81
85
  };
@@ -1,7 +1,7 @@
1
1
  #!/usr/bin/env node
2
2
  import {
3
3
  getGuardrailsPath
4
- } from "./chunk-GZ2ZAQO4.js";
4
+ } from "./chunk-EK5XS7CB.js";
5
5
 
6
6
  // src/session/guardrails.ts
7
7
  import { copyFileSync, existsSync, mkdirSync, readFileSync, writeFileSync } from "fs";
@@ -10,8 +10,8 @@ import {
10
10
  guardrailsPath,
11
11
  migrateGuardrails,
12
12
  readGuardrails
13
- } from "./chunk-UQPR5OXK.js";
14
- import "./chunk-GZ2ZAQO4.js";
13
+ } from "./chunk-N35HZN5O.js";
14
+ import "./chunk-EK5XS7CB.js";
15
15
  export {
16
16
  appendEntry,
17
17
  appendEntrySync,