@lemoncode/lemony 0.1.2 → 0.2.0

package/catalog/skills/prd-to-spec/SKILL.md

@@ -29,7 +29,7 @@ the gap by guessing — surface it (see "When the PRD is insufficient").
   real from the start — there is no `draft-<slug>` holder:
   - `requirements.md` — EARS requirements with acceptance criteria
   - `design.md` — files, functions, approach, edge cases, testing
-  - `tasks.md` — atomic, ordered, checkbox tasks
+  - `tasks.md` — atomic, ordered checkbox tasks, grouped under risk-sized step headers
 
 ## Process
 
@@ -126,16 +126,40 @@ Atomic, ordered checkboxes. Each task is a **vertical slice** (a behavior, not a
 layer) so the Implementer can run TDD red→green per task. Reference the requirements
 each task satisfies.
 
+Group the tasks under **risk-sized step headers**. In step-by-step mode the loop runs
+one implement→review→human-checkpoint cycle **per group**, so the grouping decides how
+often the human is interrupted; the human approves it at the spec gate with the rest
+of the spec. Grouping criterion:
+
+1. **Risk isolates — hard rule.** A task gets its own group iff it concentrates risk:
+   a new seam, a hard-to-reverse decision, a data-loss or security surface.
+2. **Runnable surface closes — soft rule.** Among trivial stretches, prefer group
+   boundaries that leave something the human can run at the checkpoint. Never invent
+   a group to fabricate a demo.
+3. **Soft cap: 4 tasks per group**, exceedable only with explicit justification in
+   the group's rationale (e.g. "5 identical mechanical renames").
+4. **Every group header carries a one-line boundary rationale** so the grouping is
+   auditable at the spec gate.
+
 ```markdown
 # Tasks — <topic>
 
+## Group 1 — <name> _(<one-line boundary rationale>)_
+
 - [ ] T1 — <smallest behavior that proves the path end-to-end> (R1)
 - [ ] T2 — <next behavior> (R2)
+
+## Group 2 — <name> _(<one-line boundary rationale>)_
+
 - [ ] T3 — <error path> (R2, R3)
 ```
 
 Rules: order so the first task is a tracer bullet; never "write all tests" then
-"write all code"; keep each task small enough to verify on its own.
+"write all code"; keep each task small enough to verify on its own. Grouping never
+changes task granularity — checkboxes stay atomic and TDD runs per task; only review
+and checkpoint frequency follow the groups (all-at-once mode ignores the headers).
+Tasks added mid-implementation (from a discovery) default to **their own group** —
+they are risk by definition.
 
 ### 5. Self-check before handing off
 
@@ -143,6 +167,8 @@ Rules: order so the first task is a tracer bullet; never "write all tests" then
 - [ ] Every requirement is EARS-formatted and testable.
 - [ ] At least one unwanted-behavior (`If … then …`) requirement exists.
 - [ ] Every requirement is covered by at least one task.
+- [ ] Every task sits in a group, and every group header carries a one-line
+      boundary rationale.
 - [ ] No closed PRD decision is contradicted.
 
 ### 6. Emit `spec_created`

package/catalog/skills/resolve-discovery/SKILL.md

@@ -64,7 +64,9 @@ is a second discovery — append it, don't fold it in.
 
 The agent that **created** an artifact is the one that updates it. Map the decision to
 the artifact it changes, then invoke that owner (fresh context, Task tool) with the
-decision + the entry as context:
+decision **stated in full** — at this moment it exists nowhere on disk; the entry's
+`**Resolution**` block is only written at step 4 — plus the `discoveries.md` entry
+**by path** for the surrounding context (it reads the entry itself):
 
 | Artifact changed by the decision                                     | Owner to invoke                                                                                                                                             |
 | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -104,7 +106,9 @@ do not edit the raise fields):
    Same fail-loud contract: a non-zero exit means the flag/status did not flip back.
 
 2. Re-invoke the paused sub-agent (fresh context) with: the issue, the task-state
-   paths, the decision, and the updated artifact. It picks up from where it stopped.
+   paths, a one-line gist of the decision (the full `**Resolution**` block now
+   lives in the `discoveries.md` entry — reference it), and the updated artifact's
+   **path**. It reads the files itself and picks up from where it stopped.
 
 ## Closeout invariant
 

package/catalog/skills/spec-compliance-check/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: spec-compliance-check
-description: Walk an L1 spec point by point against the implementation and emit a per-requirement pass/fail verdict. Use during review of an SDD task to prove every EARS requirement (including unwanted-behavior paths) is satisfied and tested — a committable audit trail. Complements `senior-review` (quality) with traceability (coverage of intent).
+description: Walk an L1 spec point by point against the implementation and emit a per-requirement pass/fail verdict. Use during review of an SDD task to prove every EARS requirement (including unwanted-behavior paths) is satisfied and tested — a durable audit trail. Complements `senior-review` (quality) with traceability (coverage of intent).
 origin: vendor
 vendor_version: '{{vendor_version}}'
 phase: post-implementation
@@ -11,7 +11,7 @@ invoked-by: [reviewer]
 
 `senior-review` judges whether the code is _good_; this skill proves it does what the
 **spec said** — every requirement, point by point. It produces a traceability matrix:
-a committable audit trail mapping each requirement to its implementation and its test.
+a durable audit trail mapping each requirement to its implementation and its test.
 Only meaningful for **L1 (SDD) tasks** that have a spec under
 `.claude/state/tasks/<id>/spec/`; skip it for L2.
 
@@ -25,8 +25,8 @@ Read all three spec artifacts for the task:
   state-driven / optional-feature / **unwanted-behavior**), each numbered with
   acceptance criteria.
 - `design.md` — the intended files, interfaces, approach, edge cases.
-- `tasks.md` — the atomic checklist, each item referencing the requirements it
-  satisfies.
+- `tasks.md` — the atomic checklist grouped under risk-sized step headers, each
+  item referencing the requirements it satisfies.
 
 ### 2. Trace each requirement to the implementation
 
@@ -55,6 +55,10 @@ and asserts the rejection/guard.
 
 ### 4. Emit the matrix
 
+Destination: the full-pass **issue comment**. In your return summary — and always on
+a per-step review, which posts no comment — carry only the counts + the failing
+rows, per the Reviewer's verdict-size rule.
+
 ```
 ## Spec Compliance — task #<id>
 

package/catalog/skills/task-closeout/SKILL.md

@@ -87,8 +87,9 @@ The three differ in **who decides** — and the asymmetry is deliberate:
 
 - **`update-architecture` — automatic dispatch, no pre-offer.** Only when
   `docs/architecture.md` exists (the skill installs solely then). Dispatch the
-  **Architect** (`update-architecture`, fresh context) with the task's **merged diff**
-  (`gh pr diff <pr>`) plus the task's `spec/design.md` (still live here — archival is
+  **Architect** (`update-architecture`, fresh context) with the task's **PR number**
+  (it runs `gh pr diff <pr>` itself) plus the **path** of the task's `spec/design.md`
+  (still live here — archival is
   step 4 below). The Architect reads the change, makes
   the smallest true edit if the system's **shape** moved (referencing any ADR just
   written — `see ADR-NNNN`), or reports **no-op** when nothing architectural changed.

package/catalog/skills/test-gap-report/SKILL.md

@@ -52,6 +52,10 @@ For each file in the "always" set:
 
 ### 3. Report
 
+Destination: the full-pass **issue comment**. In your return summary — and always on
+a per-step review, which posts no comment — carry only the counts + the gaps, per
+the Reviewer's verdict-size rule (a REJECT lifts the cap entirely).
+
 ```
 ## Test Gap Report — <task name>
 

package/catalog/skills/verify/SKILL.md

@@ -84,6 +84,9 @@ and the error output (unexpected warnings/errors even when the happy path worked
 **Verdict**: works / does not work — <one-line reason>
 ```
 
+This block is your working record; a capped return summary condenses it to the
+verdict line (plus any ❌ detail — failures are signal, never trimmed).
+
 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

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

@@ -57,7 +57,8 @@ A task deserves the harness if it is **specifiable**, **verifiable**, or
    `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. **UI design (if it touches UI)** — **UI design gate** (§UI design in `orchestrator.md`):
+3. **UI design (if it touches UI)** — **UI design gate** (canonical: the orchestrator's
+   L1 step 3, evaluated core-only — read `.claude/agents/ui-design.md` only when it fires):
    if the repo has a frontend AND the task touches UI, put `harness:needs-design`, offer the
    design-stop, and on "continue" **run `grill-ui` yourself** (the interactive design
    interview) to author `ui-handoff.md` under `tasks/<id>/spec/`, then dispatch the **UI
@@ -67,7 +68,7 @@ A task deserves the harness if it is **specifiable**, **verifiable**, or
    under `tasks/<id>/spec/`) then `spec-to-issue` (fills the issue body — it creates nothing
    and moves no labels).
 5. **Spec-ready + handoff** — remove `harness:needs-design` once `ui-handoff.md` is
-   complete (a spec-ready task never carries it), flip to `harness:status:spec-ready`,
+   complete (a spec-ready task never carries the label), 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?
@@ -83,8 +84,10 @@ A task deserves the harness if it is **specifiable**, **verifiable**, or
    — either lens rejecting routes back to the Implementer.
 9. **Merge gate** — never auto-merge. Surface the approved PR; the human merges (or
    authorizes you to). The task stays at `in-review` until merged.
-10. **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
+10. **Closeout** — `task-closeout`: confirm the merge via `gh`, run the three Architect
+   activations (`write-adr` — HITL offer per resolved discovery; `update-architecture` —
+   automatic when `docs/architecture.md` exists; `playbook-iterate` — HITL offer once
+   per task), 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`
@@ -92,6 +95,8 @@ A task deserves the harness if it is **specifiable**, **verifiable**, or
 
 ## L2 round-trip (TRIAGE)
 
+Authority for the steps: `.claude/agents/triage.md` (the Orchestrator's lazy companion).
+
 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).

package/dist/cli.mjs

@@ -3930,6 +3930,12 @@ const CORE_AGENTS = [
 	"architect",
 	"ui-designer"
 ];
+const COMPANION_DOCS = [
+	"fit-assessment",
+	"triage",
+	"spinoff",
+	"ui-design"
+];
 const renderFile = async (templatePath, relPath, vars) => {
 	return {
 		relPath,
@@ -3955,7 +3961,7 @@ const materializeVendorFiles = async (ctx) => {
 		SKILLS: renderRoleSkills(skills, role),
 		vendor_version: vendorVersion
 	}), vendorVersion)));
-	const fitAssessment = await copyFileEntry(join(vendorRoot, "agents", "fit-assessment.md"), join(AGENTS_DIR, "fit-assessment.md"));
+	const companionFiles = await Promise.all(COMPANION_DOCS.map((doc) => copyFileEntry(join(vendorRoot, "agents", `${doc}.md`), join(AGENTS_DIR, `${doc}.md`))));
 	const skillFiles = (await Promise.all(skills.map(async (skill) => {
 		const skillDir = join(vendorRoot, "skills", skill.name);
 		const rels = await listFiles(skillDir);
@@ -3972,7 +3978,7 @@ const materializeVendorFiles = async (ctx) => {
 	return [
 		entryProtocol,
 		...agentFiles,
-		fitAssessment,
+		...companionFiles,
 		...skillFiles,
 		playbooksReadme,
 		...hookFiles,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lemoncode/lemony",
-  "version": "0.1.2",
+  "version": "0.2.0",
   "description": "Lemony — a Harness for AI Coding. Vendor package: installer, agent role catalog, generic skill catalog, hooks, and templates for a Spec-Driven Development workflow.",
   "type": "module",
   "private": false,