@lemoncode/lemony 0.1.0

package/catalog/skills/verify/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: verify
+description: Mechanical verification of a change — the "does it work?" gate. Runs build, type-check, lint, tests + coverage, and dependency audit, then exercises the real code path. Use before signaling a change done (Implementer) and at the start of review (Reviewer, fresh context). Pairs with `senior-review`, which judges quality.
+origin: vendor
+vendor_version: '{{vendor_version}}'
+phase: post-implementation
+invoked-by: [implementer, reviewer]
+---
+
+# Verify
+
+The "**does it work?**" gate: a fixed, mechanical sequence with a pass/fail verdict.
+No judgment — that is `senior-review`'s job. The **Implementer** runs `verify` before
+signaling a change done; the **Reviewer** runs it again first thing, with fresh
+context, because re-running the gates yourself is the anti-bias point — never trust
+that they passed.
+
+## Detect the ecosystem first
+
+The gates are **language-agnostic**; only the commands differ. Read the project to
+pick them — do not assume Node:
+
+| Manifest present               | Ecosystem                              | Gate commands (typical)                     |
+| ------------------------------ | -------------------------------------- | ------------------------------------------- |
+| `package.json`                 | **Node/TS** (the worked example below) | `node --run <script>`                       |
+| `pyproject.toml` / `setup.cfg` | Python                                 | `ruff`, `mypy`, `pytest`                    |
+| `go.mod`                       | Go                                     | `go build`, `go vet`, `go test`             |
+| `Cargo.toml`                   | Rust                                   | `cargo build`, `cargo clippy`, `cargo test` |
+
+Prefer the project's declared scripts/tasks over raw tool invocations (a
+`package.json` `scripts` entry, a `Makefile` target, a `justfile` recipe) — they
+encode the project's intended flags.
+
+## The gate sequence — stop at the first failure
+
+Run in order; a failure halts the sequence (a green later gate is meaningless if an
+earlier one is red). Node/TS shown as the worked example:
+
+1. **Build** — `node --run build` (skip if the project has no build step, e.g. a
+   pure app run with `tsx`).
+2. **Type-check** — `node --run check-types` (`tsc --noEmit`).
+3. **Lint** — `node --run lint` (oxlint). Warnings are not failures unless the
+   project treats them as errors.
+4. **Tests + coverage** — `node --run test` (`vitest run`). Run with coverage when
+   the project exposes it (`node --run test:coverage`); coverage is reported, not a
+   hard gate (no thresholds — the project's testing playbook decides).
+5. **Audit** — `npm audit --audit-level=moderate` (or the ecosystem's equivalent).
+   Report advisories; a moderate+ vulnerability introduced by this change is a
+   finding.
+
+## Execution — exercise the real path
+
+Type-checks and a green suite do not prove the code runs. Identify the project's
+**archetype** (from its manifest/deps) and exercise it for real:
+
+| Archetype         | How to exercise                                                                                                                                                     |
+| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Backend / API** | Start the service; hit the affected endpoint with `curl` / an HTTP client; inspect the response and the server logs.                                                |
+| **Frontend SPA**  | Start the dev server; drive the browser to the changed view; verify rendered output and the console (no errors). Browser specifics → the client's e2e/run playbook. |
+| **SSR**           | Start the server; request the affected route; verify the rendered HTML and that hydration runs without console errors.                                              |
+| **CLI**           | Run the command on a real fixture; check stdout/stderr and the exit code.                                                                                           |
+| **Library**       | Call the public API on a fixture, or import the built artifact; confirm exports resolve.                                                                            |
+| **Worker / job**  | Trigger the job; observe the side effect (queue, DB row, emitted event).                                                                                            |
+| **Monorepo**      | Do the above for the **affected** package(s) only.                                                                                                                  |
+
+The exact launch command is the project's, not the harness's — infer it from the
+manifest scripts, and defer project-specific launch/browser steps to the client's
+**run playbook** (`docs/playbooks/run.md` or as configured). Check both the happy path
+and the error output (unexpected warnings/errors even when the happy path worked).
+
+## Report
+
+```
+## Verify — <task name>
+
+**Build**: ✅ / ❌ / N/A
+**Type-check**: ✅ / ❌
+**Lint**: ✅ / ⚠️ <warnings>
+**Tests**: ✅ <N passing> / ❌ <failure>
+**Coverage**: <reported, or N/A>
+**Audit**: ✅ / ⚠️ <advisories>
+**Execution**: ✅ <archetype + what was exercised> / ❌ <what broke>
+
+**Verdict**: works / does not work — <one-line reason>
+```
+
+On a failure, read the **full** error, find the origin (not where it surfaced), fix
+the root cause, and re-run from the failed gate. If a failure reveals the spec itself
+is wrong or silent, that's a **discovery** — run `raise-discovery`, don't paper over
+it.

package/catalog/skills/write-adr/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: write-adr
+description: Record an architecture decision as a numbered ADR in docs/adr/. Use when a discovery resolution (or an explicit request) settles a decision that is hard to reverse, surprising without context, and the result of a real trade-off — the three tests that earn an ADR. The Orchestrator invokes the Architect with this skill; it never writes an ADR for a decision that fails the tests.
+origin: vendor
+vendor_version: '{{vendor_version}}'
+invoked-by: [architect]
+trigger-condition: a resolved decision is worth recording (a discovery resolution, or an explicit request)
+---
+
+# Write ADR
+
+## Core Principle
+
+An ADR records **that** a decision was made and **why** — not how to implement it. Its
+audience is a future engineer who finds the code and asks "why on earth did they do it
+this way?" Most ADRs are a single paragraph. The value is in the record, not in filling
+out sections.
+
+This is the **Architect's** skill, invoked on-demand by the Orchestrator — typically
+when a discovery resolution settles something durable, or on an explicit request. It is
+not part of the linear implementation flow.
+
+## When an ADR is warranted (all three must hold)
+
+1. **Hard to reverse** — changing your mind later carries a meaningful cost.
+2. **Surprising without context** — a future reader would otherwise wonder why.
+3. **The result of a real trade-off** — there were genuine alternatives and one was
+   chosen for specific reasons.
+
+If a decision is easy to reverse, not surprising, or had no real alternative, **do not
+write an ADR** — say so and stop. Examples that qualify: architectural shape, an
+integration pattern between contexts, a technology choice that carries lock-in, a
+boundary/scope decision, a deliberate deviation from the obvious path, a constraint not
+visible in the code, a non-obvious rejected alternative.
+
+## Process
+
+1. **Confirm it qualifies.** Apply the three tests. If it fails, report that an ADR
+   isn't warranted and why — don't pad the log with reversible or obvious decisions.
+2. **Number it.** Scan `docs/adr/` for the highest existing `NNNN-*.md` and increment.
+   Create `docs/adr/` lazily if this is the first ADR.
+3. **Write it** to `docs/adr/NNNN-<slug>.md`. Start minimal:
+
+   ```md
+   # NNNN — {Short title of the decision}
+
+   {1–3 sentences: the context, what was decided, and why.}
+   ```
+
+   Add an optional section **only when it earns its place** (most ADRs need none):
+   - **Status** (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — when the
+     decision may be revisited.
+   - **Considered options** — when the rejected alternatives are worth remembering.
+   - **Consequences** — when non-obvious downstream effects need calling out.
+
+4. **Link, don't duplicate.** If the decision changes the architecture, the
+   `update-architecture` skill keeps `docs/architecture.md` current and references this
+   ADR — the ADR captures the _why_, the architecture doc the _shape_. Don't restate one
+   in the other.
+
+## Report
+
+Return to the Orchestrator: the ADR path and number, a one-line summary of the decision,
+or — if it didn't qualify — that no ADR was written and which test it failed. This is the
+same lightweight ADR convention `grill-with-docs` offers during a grill (`# NNNN — title`
+
+- 1–3 sentences, optional sections only when they earn their place), so ADRs born either
+  way read the same.
+
+## Uncontemplated Scenarios
+
+When a case doesn't clearly fit:
+
+1. Apply the closest matching approach with reasoning.
+2. **Flag it**: "This isn't covered by the write-adr skill. I did [approach] because
+   [reason]. Want to refine the skill?"
+3. Offer to add a rule for the case.

package/catalog/templates/README.md

@@ -0,0 +1,32 @@
+# templates/ — installer render sources
+
+> **Status: claude-code templates (P1–P4 s2).** `agents.md.tpl`,
+> `harness.config.yml.tpl`, `state/history.md.tpl`, and `docs/playbooks/README.md.tpl`
+> (the playbooks-home convention doc, P4 s2) exist and are rendered by the installer.
+> `.claude/commands/`, `.claude/settings.json`, and the rest of `docs/` land in later
+> phases.
+
+Files the installer **renders into a client repo** during `install`. Templates use
+placeholders (e.g. `{{vendor_version}}`, `{{target}}`, and the per-agent `{{SKILLS}}`
+marker) resolved from the repo capability scan. They are organized by `target`
+(decision #38), so additional targets plug in without a refactor.
+
+## Planned layout
+
+```
+templates/
+└── claude-code/                 # only operative target in Sprint 0
+    ├── agents.md.tpl            # entry protocol / dispatcher
+    ├── harness.config.yml.tpl   # config with {{capabilities}} placeholders
+    ├── .claude/
+    │   ├── agents/<role>.md.tpl  # role instances (PRE/DURING/POST filled)
+    │   ├── commands/*.md.tpl     # /resume, /define, /triage, /pause, /bypass, /hotfix
+    │   └── settings.json.tpl     # hooks, permissions
+    ├── state/
+    │   ├── current.md.tpl
+    │   └── history.md.tpl
+    └── docs/
+        ├── playbooks/README.md.tpl  # playbooks-home convention (P4 s2)
+        ├── CONTEXT.md.tpl
+        └── adr/.tpl
+```

package/catalog/templates/claude-code/.claude/settings.json.tpl

@@ -0,0 +1,34 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "startup|resume|clear",
+        "hooks": [
+          { "type": "command", "command": ".claude/hooks/init.sh" }
+        ]
+      }
+    ],
+    "SessionEnd": [
+      {
+        "hooks": [
+          { "type": "command", "command": ".claude/hooks/session-close.sh" }
+        ]
+      }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "hooks": [
+          { "type": "command", "command": ".claude/hooks/require-playbook.sh" }
+        ]
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          { "type": "command", "command": ".claude/hooks/suggest-playbook.sh" }
+        ]
+      }
+    ]
+  }
+}

package/catalog/templates/claude-code/agents.md.tpl

@@ -0,0 +1,109 @@
+# Agents — entry protocol
+
+> Lemony harness · vendor `{{vendor_version}}` · target `{{target}}`.
+> Generated by `lemony install`; safe to edit.
+
+This file is the **dispatcher** the Orchestrator follows on every session. The
+Orchestrator is the single human-facing hat; it invokes sub-agents (Spec Author,
+Implementer, Reviewer) with fresh context via the Task tool. Full role rules live
+in `.claude/agents/<role>.md`; skills in `.claude/skills/`; task state in
+`.claude/state/`.
+
+## Mode dispatcher
+
+Parse the intent of the first prompt (or honor an explicit slash command):
+
+| Intent signal | Mode |
+| --- | --- |
+| "continue", "resume", "pick up" + a `#id` or name | **RESUME** |
+| "define", "new task", "I have an idea", "I want to build" | **DEFINE** |
+| "bug", "error in", "it's broken", "fails when" | **TRIAGE** |
+| a bare greeting / orientation question / nothing | **ORIENT** |
+
+If the intent is ambiguous **between harness modes**, ask **one** disambiguation
+question, then proceed. A concrete **non-harness** request is just answered — don't
+surface the menu.
+
+- **DEFINE** — the L1 full-SDD round-trip (see below).
+- **RESUME** — for an SDD task, `git fetch` and check out `harness/<id>-<slug>` first
+  (the task state and spec live only on the branch until merge), then reload
+  `.claude/state/tasks/<id>/` and continue from `progress.md`.
+- **TRIAGE** — the L2 lightweight path (see below). Invoke the `triage-issue` skill.
+- **ORIENT** — an intentless entry (greeting / "what should I pick up?" / nothing).
+  Render the **dispatch menu**: the parked queue (the same listing `/resume` runs with
+  no args — including the **`/spinoff` pending stubs**) plus the start options `/define`
+  and `/triage`, and ask which to do. The start options are **unconditional** — an empty
+  queue still renders the menu with just them. Best-effort and offline-safe: if `gh` is
+  absent or unauthenticated, skip the listing and still offer the start options — never
+  block.
+  Authority + the full guard: `.claude/agents/orchestrator.md` §Dispatch → ORIENT.
+
+## Task-fit dial
+
+The harness is a dial, not on/off (decisions #57–#61):
+
+- **L1 — full SDD**: real features. Grill → spec → human gate → implement → review.
+- **L2 — lightweight**: small bugs. Issue + state + implement (TDD) + light review.
+- **L3 — bypass**: typos, mechanical renames, lockfile bumps. No issue, no review.
+
+A task deserves the harness if it is **specifiable**, **verifiable**, or
+**reviewable** (≥1). If none → L3. When in doubt, keep it in the harness.
+
+## L1 round-trip (DEFINE)
+
+1. **Grill** — `grill-with-docs`: interview the idea into a PRD at
+   `docs/prds/<topic>-<date>.md`.
+2. **Open the task** — create the issue (skeleton body + `harness:managed` +
+   `harness:sdd` + `harness:status:spec-in-progress`) and the branch
+   `harness/<id>-<slug>`. `<id>` is the GitHub issue number in this build; spec and code
+   both live on that branch — nothing touches the default branch until the merge gate.
+3. **Spec** — Spec Author sub-agent (given the `<id>` + branch): `prd-to-spec` (→
+   `requirements.md` EARS + `design.md` + `tasks.md` under `tasks/<id>/spec/`) then
+   `spec-to-issue` (fills the issue body — it creates nothing and moves no labels).
+4. **Spec-ready + handoff** — flip to `harness:status:spec-ready`, commit and push the
+   task state to the branch. DEFINE can stop here: the spec-ready queue
+   (`gh issue list -l harness:status:spec-ready`) is the handoff. Ask: implement now or
+   hand off?
+5. **Approval gate** — run by whoever implements (a RESUME of a spec-ready issue runs
+   it). Present the spec; the human approves (or asks for changes → Spec Author
+   revises). On approval, flip to `harness:status:in-progress`. The spec, not the code,
+   is the source of intent — never self-approve.
+6. **Implement** — Implementer sub-agent, `tdd` skill, on the branch, keeping
+   `.claude/state/tasks/<id>/progress.md` live.
+7. **Review** — flip to `harness:status:in-review`, open the PR (`gh pr create`,
+   branch → default), Reviewer sub-agent reviews it (`senior-review`, fresh context).
+8. **Merge gate** — never auto-merge. Surface the approved PR; the human merges (or
+   authorizes you to). The task stays at `in-review` until merged.
+9. **Closeout** — `task-closeout`: confirm the merge via `gh`, offer durable discoveries
+   to the Architect (`write-adr`, HITL), archive the spec + discoveries to `_archive/<id>/` (drop
+   `progress.md`), and land `history.md` + the archival via a dedicated
+   `harness/closeout-<id>` PR (`gh pr merge --auto`) — never a direct push to the base.
+   If protection needs approval the PR waits: park at `closeout-pending`, `/resume`
+   finalizes. Then close the issue and delete the branch.
+
+## L2 round-trip (TRIAGE)
+
+1. **Triage** — `triage-issue`: investigate, find root cause, draft a TDD-based fix
+   plan, and create the issue with `harness:managed` (no `harness:sdd` — its absence
+   marks the lightweight path).
+2. **Branch + scaffold** — create the branch `harness/<id>-<slug>`, scaffold
+   `progress.md` on it (nothing touches the default branch until the merge gate).
+3. **Implement** — Implementer sub-agent, `tdd` skill.
+4. **Review** — flip to `harness:status:in-review`, open the PR, Reviewer sub-agent
+   (`senior-review`, fresh context).
+5. **Merge gate** — the same human-explicit gate as L1: never auto-merge.
+6. **Closeout** — `task-closeout`: confirm the merge, archive the spec + discoveries to
+   `_archive/<id>/`, and land `history.md` + the archival via a dedicated
+   `harness/closeout-<id>` PR (`gh pr merge --auto`); park at `closeout-pending` if it
+   needs approval. Then close the issue and delete the branch. Same as L1.
+
+## Discovery interrupts (decision #30)
+
+At any step, a sub-agent that hits a T1–T6 case (contradiction, unspecified decision,
+scope drift, existing solution, infeasibility, playbook conflict) **pauses instead of
+guessing**: it runs `raise-discovery`, writing `tasks/<id>/discoveries.md` and
+returning a one-line summary. The Orchestrator then runs `resolve-discovery` — the
+task moves to `harness:status:paused-for-clarification` (+ `harness:discovery:T*`), the
+human arbitrates, the owning agent updates its artifact, and the paused sub-agent
+resumes. No discovery may remain unresolved at closeout. Details in
+`.claude/agents/*.md`.

package/catalog/templates/claude-code/docs/playbooks/README.md.tpl

@@ -0,0 +1,96 @@
+# Playbooks
+
+This folder holds your project's **playbooks** — project-agnostic documents describing
+*how to build* a category of software here (a backend service, an SPA, a testing
+strategy, a release flow). Agents read them as canonical patterns while implementing and
+reviewing.
+
+Playbooks are **yours**. The harness defines *where to look* and *the format*; it ships
+**no** playbook content (you own your architecture). This file documents the lookup
+convention — it is safe to keep, edit, or replace.
+
+## The lookup convention
+
+A playbook is found by its **topic filename**, `<topic>.md`, across two layers:
+
+1. **Project-local** — `docs/playbooks/<topic>.md` (here). Committed with the repo.
+2. **Global** — your personal, generic playbooks at `~/.claude/playbooks/` (default).
+
+> Both locations are **configurable** in `harness.config.yml`: `paths.playbooks`
+> (repo-relative) moves this local layer, `paths.playbooks_global` (absolute or
+> `~`-based) moves the global one. The hooks read those keys on every fire, so a
+> change takes effect immediately — no install or restart. Leave a key unset to
+> keep the default.
+
+Lookup is **local → global**, and a **local file overrides** the global one for the same
+topic. There is **no index or manifest** — the filename *is* the registry (an index only
+drifts out of sync). A missing playbook is **not an error**: skills that consult one
+degrade gracefully when it's absent.
+
+Common topics: `run.md` (how to launch the app), `testing.md`, `e2e.md`, `<stack>.md`.
+Use whatever topic names your skills and team reach for.
+
+## Enforcement (P5 slice 2)
+
+Two Claude Code hooks read this folder on every turn:
+
+- **`require-playbook.sh`** (`PreToolUse` on `Write`/`Edit`) — blocks the call when the
+  target file path matches a playbook's `applies_to` glob list and that playbook has not
+  been read in this conversation. The block message names the exact playbook(s) to read
+  and the path. After reading, the agent retries the Write/Edit.
+- **`suggest-playbook.sh`** (`UserPromptSubmit`, non-blocking) — emits a
+  `<system-reminder>` when the prompt matches a playbook's `keywords` regex list and
+  that playbook has not been read yet.
+
+Add a playbook → the hooks pick it up on next fire (no install/restart).
+
+> **Where they live / how to verify.** These hooks are installed in **this project's**
+> `.claude/hooks/` and wired in `.claude/settings.json` (`PreToolUse` / `UserPromptSubmit`)
+> — **not** in your global `~/.claude/hooks/`. To confirm enforcement is active, run
+> `lemony doctor` (its `hooks` check reports it) or inspect `.claude/settings.json`.
+> Checking `~/.claude/hooks/` gives a **false negative**. Note that a playbook with only
+> `keywords` (no `applies_to`) is suggest-only **by design** — it never blocks a Write/Edit.
+
+## Format at a glance
+
+```markdown
+---
+name: testing
+applies_to:
+  - "**/*.spec.ts"
+  - "**/*.bench.ts"
+keywords:
+  - "vitest"
+  - "test runner"
+status: active
+---
+
+# Testing
+
+(canonical patterns here…)
+```
+
+- `name` (required) — kebab-case, equals the filename stem.
+- `applies_to` (optional) — bash globs. **Files matching any glob require this playbook.**
+- `keywords` (optional) — case-insensitive regexes (Oniguruma). **Prompts matching any regex suggest this playbook.**
+
+`applies_to` and `keywords` are independently optional: a playbook can be require-only,
+suggest-only, both, or neither. The full spec lives in
+[`catalog/playbook-format.md`](https://github.com/{{task_storage_repo}}/blob/main/catalog/playbook-format.md)
+(packaged with the vendor — referenced here for convenience).
+
+## What belongs here (and what doesn't)
+
+A playbook is **project-agnostic**: it uses placeholder names (`@org/x`, `<your-app>`,
+`getResourceById`) and describes the *pattern*, never this codebase's real symbols.
+
+Project-**specific** rules — a business rule, a quirk of one app, a one-off integration —
+do **not** go in a playbook. They belong in `CLAUDE.md`, a project-local ADR
+(`docs/adr/`), or `CONTEXT.md`.
+
+## Creating and iterating playbooks
+
+- Author one by hand following the format above, or
+- ask the **Architect** to extract one from the codebase (its `playbook-iterate` skill
+  can capture a pattern the code already follows, or revise a playbook when a spec
+  collides with it — a `T6 PLAYBOOK_CONFLICT`). The Architect proposes; you decide.

package/catalog/templates/claude-code/harness.config.yml.tpl

@@ -0,0 +1,59 @@
+# yaml-language-server: $schema=./harness.config.schema.json
+# Lemony — harness configuration.
+# Generated by `lemony install`. Safe to edit; `install` refuses to overwrite
+# this file — use `repair` to re-sync at the pinned version, or `update` to change
+# the pinned version. The `$schema` header above
+# gives an IDE (VS Code YAML extension) autocomplete + inline validation from the
+# committed `harness.config.schema.json` the installer drops next to this file.
+
+# Vendor catalog version this instance is pinned to (exact pin during the pilot).
+vendor_version: {{vendor_version}}
+
+# AI-coding harness this install targets. Only `claude-code` is operative today.
+target: {{target}}
+
+# Where managed tasks live. Auth is delegated to the `gh` CLI (no token here).
+task_storage:
+  type: github
+  repo: {{task_storage_repo}}
+
+# Active agents (one `.claude/agents/<role>.md` per entry).
+agents:
+  - orchestrator
+  - spec-author
+  - implementer
+  - reviewer
+  - architect      # always installed; invoked on-demand, outside the linear flow
+  # - ui-designer  # catalog slot, inactive by default (decision #11)
+
+# Paths (relative; defaults shown — declare only overrides).
+paths:
+  state: .claude/state
+  skills: .claude/skills
+  agents: .claude/agents
+  # Project-local playbooks (how-to-build patterns). Looked up by convention
+  # `<topic>.md`, local then global; the local entry overrides the global one.
+  # The require/suggest hooks read these two keys directly on every fire, so a
+  # change takes effect immediately (no install/restart). Set `playbooks` to a
+  # repo-relative dir to relocate the local layer.
+  playbooks: docs/playbooks
+  # Global playbook layer (dev-owned, generic). Default `~/.claude/playbooks`.
+  # Uncomment and set (absolute or `~`-based) to relocate the global layer.
+  # playbooks_global: ~/.claude/playbooks
+
+# Rollback snapshots. Each `update` bundles the pre-update vendor tree under
+# `.claude/.harness/snapshots/<from-version>/` (gitignored); `rollback` restores it.
+rollback:
+  # How many snapshot bundles to retain (rotation drops the oldest). A positive
+  # integer or `unlimited` (never rotate). Default 3.
+  keep_snapshots: 3
+
+# Anonymous usage telemetry — ON by default. At session close the harness sends an
+# anonymized, identifier-free projection of local events to improve the tool.
+# Three ways to opt out (highest precedence first):
+#   1. env `LEMONY_TELEMETRY_DISABLED=1` (this shell/machine),
+#   2. `lemony telemetry disable` (this checkout only, not committed),
+#   3. the committed switch below (the whole team, for this repo).
+# Uncomment to opt the team out:
+# telemetry:
+#   enabled: false

package/catalog/templates/claude-code/state/history.md.tpl

@@ -0,0 +1,6 @@
+# History
+
+Append-only changelog — one line per finished task (cycle time, tokens, post-merge
+bugs, iterations). Written by the Orchestrator at closeout.
+
+_No tasks completed yet._