---
requires: wave/<chord>/
produces: scratch/garden-scan.md
---
Read the territory. Understand what each member wave has done, is doing, and is stuck on.
## Orientation
Before starting, orient yourself in this branch:
- Read `scratch/` — design docs and notes for the current work live here
(`scratch/<branch>.md` is this PR's design; `scratch/questions.md` holds open
questions and assumptions).
- Read wave/PM context only when the seed names the exact wave, task, project,
or a concrete coordination question; never infer it or repair access as a
prerequisite.
- Read the repo's agent doc (`CLAUDE.md` / `AGENTS.md`) for conventions.
Write design artifacts, notes, and open questions under `scratch/`. Don't
re-derive what these already record.
## Scope
The chord-wave's area lists member wave directories. Each directory contains a
`GOAL.md` and `MEMORY.md`; Chapter definition, KRs, and Tasks come from its PM
snapshot. This step reads all of it, plus the living state around it.
Member wave names come from those directory names. If the chord-wave area
contains `wave/chord-model/` and `wave/signals/`, the wave names are
`chord-model` and `signals`.
## Workflow
1. **Read wave configs.** For each member wave directory in the area:
- `GOAL.md` — objective, cadence, policy, and the Linear handle
- `MEMORY.md` — what the wave has learned and decided
- `lf status <wave> --json` — current chapter, KRs, and Tasks from SQLite
- `lf status <wave> --json` — the Wave-owned live metric portfolio
Linear is the source of truth; there are no local Project or Task lists.
2. **Read runtime state.** For each member wave:
- `lf status <wave-name> --json` — Wave presence, resident state, current chapter, Tasks, next owners, worktrees, PRs, and conditions
- `lf task status <issue-id> --json` only when the Wave snapshot needs
deeper inspection
Do not infer product state from tmux names or branch naming.
3. **Read recent activity.** For each member wave:
- `git log main --since="1 week ago"` filtered to the wave's area paths
- Open PRs owned by the Wave's Tasks
- CI status on open PRs
- Any `scratch/` artifacts from in-progress work
4. **Read unlanded branches.** Look for work that was pushed but never landed:
- Start from each Task's persisted branch and worktree
- For each Task branch ahead of main, show `git log main..<branch> --oneline`
and `git diff --stat main..<branch>`
- Check whether a PR exists for the branch (`gh pr list --head <branch>`)
- Note branches with significant unlanded commits — these represent
work the wave already did that the chord can't see from main alone
- Check Task worktrees too (`lf wt list`) — a worktree with
uncommitted changes or unpushed commits is the same signal. Low-level
worktrees not attached to a Task are diagnostic state, not roadmap work.
5. **Read blocks.** Look for signals that a wave is stuck:
- PRs with failing CI that haven't been fixed
- Tasks or other Work with no recent activity
- Merge conflicts
- Open questions in `scratch/questions.md`
6. **Read cross-wave state.** Look for interactions between waves:
- PRs that touch files in another wave's area
- Tasks in different waves that reference the same code
- Dependency ordering (does wave A's work block wave B?)
## Task references
When the scan names more than one Task, read `lf roadmap --wave <wave> --json`
for plan-wide rows and `lf status <wave> --json` for live execution. Render
operational Task lists with the shared reference:
```markdown
[identifier · Task title](provider URL) — status; next action/owner
```
Use this ID-first form in operational lists. In prose, use
`[Task title · identifier](provider URL)` on first mention; shorten later
references when unambiguous.
Fill the link from `task.identifier` and `reference.issue_url`, and the readable
title from `task.title`. Take status from `runtime.status` or the roadmap
`section`, and next owner from `next_move.owner`. State the next action only
when supported by current evidence; leave unknown state unknown. Include an
active PR/workspace slug only when navigating that workspace is the job. In
roadmap, use `active_pr.slug`; in status, match `active_pr` to `prs[].id` and
use that PR's `slug`. Fall back to `reference.workspace.slug`. Never infer a
URL, branch, or slug from a title or identifier. If a link is absent, keep the
readable title and available status without inventing a URL.
## Output
Write `scratch/garden-scan.md`:
```markdown
# Tend Scan — <date>
## Wave: <name>
### Config
<objective, cadence, policy, PM binding>
### Runtime
<Wave presence and resident state, active Tasks, conditions>
### Progress
<what shipped recently, what's in flight>
### Chapter
<Current KRs, dated evidence, next owner>
### Tasks
<[identifier · Task title](provider URL) — status; next action/owner,
followed by relevant evidence>
### Blocks
<anything preventing progress — CI failures, conflicts, stalls, missing decisions>
### Open PRs
<PR number, title, CI status, age>
### Unlanded Branches
<branch name, commits ahead of main, diff stats, PR status (none/open/closed)>
(repeat for each member wave)
## Cross-Wave
<interactions, dependencies, conflicts between waves>
## Raw Signals
<anything notable that doesn't fit above — patterns, surprises, anomalies>
```
## What to avoid
**Interpretation.** This step observes. It doesn't judge priorities, suggest changes, or
evaluate quality. That's assess's job.
**Staleness.** Run the commands. Don't rely on memory or cached state. The scan must
reflect the repo as it is right now.
**Partial reads.** Read the full chapter plan and every Task in each Wave's PM/status snapshot.
Skipping filed or running work means the assessment will miss things.