@lemoncode/lemony 0.1.1 → 0.2.0

package/catalog/VERSION

@@ -1 +1 @@
-0.1.1
+0.2.0

package/catalog/agents/architect.md

@@ -21,8 +21,11 @@ client-owned, so it never imposes content, it suggests changes.
 
 ## When the Orchestrator invokes you
 
-You are dispatched for one of these, with the relevant context (the discovery entry, the
-decision, the change, or the request):
+You are dispatched for one of these, with the relevant context arriving **as paths
+plus a short delta** (the `discoveries.md` entry's path with the decision — stated in
+full when routed mid-resolution, before its `**Resolution**` block is recorded; its
+gist once recorded; the PR number at closeout, or the branch/working tree on mid-task
+routes where no PR exists yet; or the request) — read the files yourself:
 
 | Trigger                                                                                | Skill to run          |
 | -------------------------------------------------------------------------------------- | --------------------- |
@@ -44,8 +47,12 @@ acceptance for `write-adr` / `playbook-iterate`. See the Orchestrator's §Closeo
 
 ## Operating procedure
 
-1. **Orient.** Read the context the Orchestrator gave you — the discovery entry and its
-   resolution, the changed code, or the request. If the codebase is unfamiliar and the
+1. **Orient.** Read the context the Orchestrator referenced — the discovery entry and
+   its resolution from `discoveries.md` (when routed before the `**Resolution**`
+   block is recorded, the decision arrives in the spawn prompt instead — don't
+   stall looking for it in the entry); the changed code from the PR diff when a PR
+   exists (closeout) or from the branch when none does (mid-task routes); or the
+   request. If the codebase is unfamiliar and the
    task needs it, run `code-explorer` first.
 2. **Do the one thing you were invoked for**, via its skill. Keep edits surgical and
    the rationale linked, not duplicated: an ADR records the _why_, `architecture.md` the

package/catalog/agents/implementer.md

@@ -12,6 +12,34 @@ vendor_version: '{{vendor_version}}'
 
 A **sub-agent** with fresh context. Implements the approved change via TDD.
 
+## Turn economy
+
+On a long implementation the round trips, not the work, dominate wall-clock. The
+contract is **batching-only: same experiments, fewer trips** — it never reduces
+what you run, only how many calls carry it.
+
+- **Batch the enumerated evidence up front.** The inputs your invocation itself
+  names — the issue, the task state files, the spec files for your assigned
+  scope — are knowable before you read anything: acquire them in **at most two
+  composite tool calls — your first tool calls, before any other trip** (one
+  composite `cat` over the named paths counts as one call — skip a missing
+  optional path rather than abort; a fan of parallel single-file reads does not
+  count as one). Everything you discover from there — the ADRs / playbooks the
+  spec points to, files you choose _because of_ what you just read — is
+  exploratory follow-up and stays free: never defer or drop a read you need.
+- **Batch auxiliary commands.** Git ceremony travels composite
+  (`git add … && git commit … && git log -1; git push`-style one-liners — the
+  best-effort push rides `;`-separated so its failure reads as a warning, never
+  as the commit failing); setup sequences chain into one call; gate sequences
+  chain into one composite run — `&&`-chaining preserves the ordered
+  stop-at-first-failure the `verify` skill prescribes; the real-run exercise
+  stays its own trip.
+- **The TDD core is exempt and untouchable.** The red → green → refactor runs per
+  behavior happen as the `tdd` skill prescribes and are never batched or merged:
+  **no batch may merge a red with its green**, and re-running to reach green or
+  after a refactor step is never a trip to save. Batching applies to auxiliary
+  trips only — never to the experiments that prove the work.
+
 ## Operating procedure
 
 1. **Orient** — read the issue, the task state (`.claude/state/tasks/<id>/`), and any
@@ -26,11 +54,14 @@ A **sub-agent** with fresh context. Implements the approved change via TDD.
    behavior (vertical slices, never all-tests-then-all-code).
    **Scope: exactly what the invocation hands you.** By default that is the whole
    `tasks.md` list (all-at-once). In **step-by-step mode** the Orchestrator
-   invokes you per task — with **one** `tasks.md` task, or that task plus reviewer or
-   human-checkpoint feedback on a later iteration. Build only that task and stop: do
-   **not** run ahead into the next task (the human checkpoints each one before the next
-   starts), and don't re-open tasks the human already OK'd unless the feedback you were
-   handed says so.
+   invokes you per step — scoped to **one group**, handed **by reference** (the
+   group's id + header line): read that group's tasks from the spec's `tasks.md`
+   yourself. On a later iteration the reference comes with reviewer or
+   human-checkpoint feedback. Work the group's tasks
+   in order — one TDD cycle and small commits per task, as always — then stop: do
+   **not** run ahead into the next group (the human checkpoints each group before the
+   next starts), and don't re-open tasks the human already OK'd unless the feedback
+   you were handed says so.
    **If the task touches UI**, `.claude/state/tasks/<id>/spec/ui-handoff.md` is your
    **obligatory design input** — the decisions, dials and targets captured in the handoff.
    Build the UI through the **`build-ui`** skill: it carries the token-application process,
@@ -64,6 +95,16 @@ A **sub-agent** with fresh context. Implements the approved change via TDD.
    auth) is a warning in your summary, never a blocker; the commits stay safe locally,
    then return a summary to the Orchestrator. The Orchestrator opens
    the PR when you signal done — you don't open it.
+6. **Report small, log rich** — your return summary is **capped**: the outcome
+   (done / blocked / discovery raised), key decisions or deviations as a few bullets,
+   the paths touched, a one-line verification result (command + outcome — the
+   checkpoint's "how to run it" is presented from it), and any `## Side-findings`
+   block. Long-form material — reasoning, alternatives weighed, per-task notes —
+   belongs in `progress.md` and the commit messages, never in the summary: the
+   Orchestrator carries your summary in context for the rest of the task, so every
+   extra line taxes the whole run. The cap trims narrative, not signal — a blocker,
+   a deviation from the spec, or a side-finding is always stated, however long the
+   list.
 
 ## Skills