Layered run UI, one-command start, and live-testing fixes, accept DL-011 (+DL-014)

.claude/skills/dld-reindex/scripts/list-taken-ids.sh

@@ -48,10 +48,12 @@ PR_BASE="${BASE#origin/}"
 
   # IDs in files touched by open PRs targeting this base. Scope to paths under
   # the records dir so an unrelated PR touching e.g. notes/DL-007-meeting.md
-  # doesn't poison the taken set.
+  # doesn't poison the taken set. A PR whose head is the current branch is not
+  # a collision: it holds this branch's own decisions.
   if [[ -z "$SKIP_REASON" ]]; then
-    gh pr list --state open --base "$PR_BASE" --json files --limit 100 \
-      --jq '.[].files[].path' 2>/dev/null \
+    CURRENT_BRANCH="$(git -C "$PROJECT_ROOT" branch --show-current 2>/dev/null || true)"
+    gh pr list --state open --base "$PR_BASE" --json files,headRefName --limit 100 \
+      --jq ".[] | select(.headRefName != \"$CURRENT_BRANCH\") | .files[].path" 2>/dev/null \
       | grep -E "^${RECORDS_DIR_REL}/" \
       | grep -oE 'DL-[0-9]+' || true
   fi

decisions/INDEX.md

@@ -2,9 +2,11 @@
 
 | ID | Title | Status | Tags |
 |----|-------|--------|------|
+| DL-015 | Rename dld-goal to dld-run: the command is a run, not a goal | proposed | dld-goal, naming, ux |
+| DL-014 | Amend DL-008: Esc suspends the loop; pause aborts the current turn | accepted | dld-goal, extension, execution |
 | DL-013 | Amend DL-008: continuation is a scheduled dispatch, not an awaited handler | accepted | dld-goal, extension, execution |
 | DL-012 | Amend DL-007: correct the delegated script list | accepted | dld-goal, architecture, state |
-| DL-011 | Run visibility is layered: status line, fixed-height widget, transcript cards, board overlay | proposed | dld-goal, extension, ui |
+| DL-011 | Run visibility is layered: status line, fixed-height widget, transcript cards, board overlay | accepted | dld-goal, extension, ui |
 | DL-010 | Compaction during a run is assembled deterministically from disk, never model-summarised | proposed | dld-goal, extension, context |
 | DL-009 | Child-session rotation is a re-entrant controller driven by a typed tool, verified against disk | proposed | dld-goal, extension, architecture |
 | DL-008 | In-session continuation fires on agent_end behind idle, token, and bounds gates | accepted | dld-goal, extension, execution |

decisions/records/DL-011.md

@@ -2,11 +2,21 @@
 id: DL-011
 title: "Run visibility is layered: status line, fixed-height widget, transcript cards, board overlay"
 timestamp: 2026-08-21T12:19:17Z
-status: proposed
+status: accepted
 supersedes: []
 amends: []
 tags: [dld-goal, extension, ui]
-references: []
+references:
+  - path: extensions/dld-goal/render.ts
+    symbol: widgetLines
+  - path: extensions/dld-goal/render.ts
+    symbol: statusLine
+  - path: extensions/dld-goal/render.ts
+    symbol: boardLines
+  - path: extensions/dld-goal/render.test.ts
+  - path: extensions/dld-goal/surfaces.test.ts
+  - path: extensions/dld-goal/index.ts
+    symbol: refreshSurfaces
 ---
 
 ## Context
@@ -59,6 +69,8 @@ The run uses all four, matched to what each is good at.
 
 Notifications remain for transitions the user must not miss: a blocked item, a bound reached, a run completing.
 
+The widget height is fixed at **five lines**: header, up to three item rows, and a `+N before · +N more` line when items fall outside the window. Height invariance is a unit-tested property (`render.test.ts` renders 3-item and 30-item runs and asserts identical line counts). Surfaces repaint on `session_start`, `turn_end`, `agent_end`, and after every `/dld-goal` command, and clear entirely when no run is active. Without a UI (print/RPC), nothing is painted.
+
 ## Rationale
 
 Each kind of content sits where its cost is acceptable. Detail that a developer wants once — what exactly the checks returned — belongs in scrollback, where it is free to render, readable later, and diffable against the run log. Detail wanted continuously — where am I, how much budget is left — belongs in one or two lines that never grow.

decisions/records/DL-014.md

@@ -0,0 +1,34 @@
+---
+id: DL-014
+title: "Amend DL-008: Esc suspends the loop; pause aborts the current turn"
+timestamp: 2026-08-22T09:56:06Z
+status: accepted
+supersedes: []
+amends: [DL-008]
+tags: [dld-goal, extension, execution]
+references:
+  - path: extensions/dld-goal/index.ts
+    symbol: dldGoalExtension
+---
+
+## Context
+
+DL-008 promised "Esc pauses the run" but the extension had no mechanism for it. Live testing confirmed the failure: pressing Esc aborts the current turn, `agent_end` fires, the loop sees an active run with work, and dispatches the same item again immediately. The user watches the loop restart itself twice before realising Esc doesn't stop it.
+
+DL-013 established that suspension is explicit state, but only covered typed input. Esc is the other half of the same contract.
+
+## Decision
+
+Amend DL-008 to cover interrupt-driven suspension:
+
+- An `agent_end` whose last assistant message has `stopReason: "aborted"` is the user pressing Esc. The loop suspends, clears any pending dispatch, and notifies "Run suspended (interrupted). /dld-goal resume to continue."
+- `/dld-goal resume` clears suspension and dispatches immediately, so the standard interrupt and the standard resume form a matched pair.
+- `/dld-goal pause` additionally calls `ctx.abort()`, so pausing mid-turn stops the current work rather than letting the agent finish what it was doing.
+
+## Rationale
+
+Esc is the harness's standard interrupt. A loop that overrides it is worse than no loop — the user's one reliable escape hatch becomes the thing that makes the problem worse. Suspending on abort is the only behavior that respects both the interrupt and the loop's purpose.
+
+## Consequences
+
+The user can always stop the loop with Esc, and always restart it with `/dld-goal resume`. Idle continuation (the loop driving when the user isn't watching) is unaffected — the abort check only fires on an actual abort, not on normal turn completion.

decisions/records/DL-015.md

@@ -0,0 +1,36 @@
+---
+id: DL-015
+title: "Rename dld-goal to dld-run: the command is a run, not a goal"
+timestamp: 2026-08-25T11:34:38Z
+status: proposed
+supersedes: []
+amends: []
+tags: [dld-goal, naming, ux]
+references: []
+---
+
+## Context
+
+The goal-loop command and skill are named `/dld-goal`, borrowed from the pi ecosystem (pi-goal, pi-goal-pro, pi-goal-x). Within DLD the vocabulary is decisions, plans, and runs — the run contract already calls the thing a run (`create-run.sh`, `run-state.sh`, `status: active`). "Goal" is the ecosystem's word, not the domain's, and it reads as "set a goal" rather than "execute a batch of decisions."
+
+The question surfaced while dogfooding: `/dld-goal start DL-014..DL-022` works, but the name doesn't say what happens. Alternatives considered: `/dld-batch-implement` (accurate but clunky), `/dld-implement --run` (folds into the existing verb but changes its semantics), `/dld-execute` (generic).
+
+## Decision
+
+Rename the command, skill, and extension from `dld-goal` to `dld-run`. The concept is a run: a set of proposed decisions executed as one long-running unit. The name should match the artifacts the user already sees — `.dld/runs/<slug>/`, `run-state.sh`, the run contract.
+
+This is a rename, not a redesign. Every file, command, script path, and reference changes; the behavior does not. The change is deferred until after the current PR stack lands, so the rename doesn't entangle with the v1 implementation still in flight.
+
+## Rationale
+
+The name you type every day should be the name of the thing. "Run" is already the contract's word, the filesystem's word, and the status line's word. Aligning the command with them removes the translation step between what the user says and what the system does.
+
+`/dld-run` is also shorter than `/dld-goal` and unambiguous in a way "goal" is not: a goal is an aspiration, a run is an execution. The command executes.
+
+## Consequences
+
+Every reference changes: skill directories (`skills/dld-goal/` → `skills/dld-run/`), the extension directory, command names, script names, documentation, decision records that mention "goal", the plugin manifest, and the pi package manifest. The two-copy skill layout means each change lands twice.
+
+Existing runs in `.dld/runs/` are unaffected — the directory name doesn't change, only the command that creates them.
+
+The pi ecosystem already has several `goal` extensions; `dld-run` avoids colliding with any of them in the command namespace.

docs/plan/goal-loop.md

@@ -163,9 +163,9 @@ On session start with an active run in `.dld/runs/`:
 
 ## Build order
 
-1. **`/dld-goal` skill (manual pacing).** Contract authoring, state files, the execution loop driven by the agent in one session, the four-part completion transaction composed from existing scripts. Works everywhere DLD works today. This is most of the semantics and none of the harness risk.
-2. **Extension v1: in-session continuation.** `/dld-goal` commands, `agent_end` continuation with idle/pending checks and run tokens, status widget, bounds, pause/resume. No child sessions yet — the loop runs in the controller session.
-3. **Extension v2: child sessions + deterministic compaction.** Fresh session per item, disk-backed recovery, deterministic compaction summaries.
+1. **`/dld-goal` skill (manual pacing).** ✅ Done — 10 scripts, 305 bats tests, validated end-to-end.
+2. **Extension v1: in-session continuation.** ✅ Done — `/dld-goal` commands with tolerant start syntax (`DL-014..DL-022`), scheduled `agent_end` continuation with suspension on user input and Esc, completion transaction honouring review mode, layered UI (status line, fixed-height widget, transcript cards, board overlay), active-time bounds. 96 bun tests alongside the bats suite. DL-006 through DL-014 accepted.
+3. **Extension v2: child sessions + deterministic compaction.** Fresh session per item, disk-backed recovery, deterministic compaction summaries (DL-009, DL-010, still proposed).
 4. **Later, if earned:** detached auditor process, regression-shield audit automation, `/dld-audit-auto` integration for fully unattended runs with a PR at the end.
 
 Each stage ships usable; later stages only add autonomy.