@cloverleaf/reference-impl 0.7.2 → 0.7.4

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "cloverleaf",
   "description": "Cloverleaf reference implementation — Claude Code skills for task scaffolding and the Delivery pipeline (implementer, documenter, reviewer, UI reviewer with multi-viewport visual diff, QA, merge, release).",
-  "version": "0.6.5",
+  "version": "0.7.4",
   "author": {
     "name": "Renato D'Arrigo",
     "email": "renato.darrigo@gmail.com"

package/VERSION

@@ -1 +1 @@
-0.6.0
+0.7.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cloverleaf/reference-impl",
-  "version": "0.7.2",
+  "version": "0.7.4",
   "description": "Reference implementation of the Cloverleaf methodology as Claude Code skills. Implements the Tight Loop (Implementer + Reviewer).",
   "type": "module",
   "license": "MIT",
@@ -40,6 +40,7 @@
     "cloverleaf-cli": "./dist/cli.mjs"
   },
   "scripts": {
+    "pretest": "node scripts/check-standard-prepped.mjs",
     "test": "tsc --noEmit && vitest run",
     "test:watch": "vitest",
     "typecheck": "tsc --noEmit",
@@ -48,7 +49,7 @@
     "prepublishOnly": "node scripts/check-standard-prepped.mjs && npm test && npm run build"
   },
   "dependencies": {
-    "@cloverleaf/standard": "^0.5.0",
+    "@cloverleaf/standard": "^0.6.0",
     "ajv": "^8.17.1",
     "ajv-formats": "^3.0.1",
     "axe-core": "^4.10.0",

package/skills/cloverleaf-new-task/SKILL.md

@@ -32,13 +32,23 @@ The user has invoked this skill with a brief. Your job: turn the brief into a st
      "owner": { "kind": "agent", "id": "implementer" },
      "project": "<project>",
      "title": "<concise title derived from brief>",
-     "context": {},
+     "context": <see "context.rfc injection" below>,
      "acceptance_criteria": ["<criterion 1>", "<criterion 2>", "..."],
      "definition_of_done": ["<terminal statement of completion>"],
      "risk_class": "low"
    }
    ```
 
+   **`context.rfc` injection:**
+
+   - If the brief includes `--rfc=<RFC-ID>` (e.g. `/cloverleaf-new-task --rfc=CLV-9 "Brief text..."`), read `<repo_root>/.cloverleaf/rfcs/<RFC-ID>.json` and inject the workItemRef shape:
+     ```json
+     "context": { "rfc": { "project": "<rfc-project-field>", "id": "<RFC-ID>" } }
+     ```
+     The `project` field comes from the loaded RFC document, NOT the task's own project (a task in project FOO may legitimately reference an RFC in project BAR).
+   - If `<repo_root>/.cloverleaf/rfcs/<RFC-ID>.json` does not exist, abort and ask the user to verify the RFC ID. Do not write the task file.
+   - If `--rfc=<ID>` is not passed, leave `context` as `{}` — same as pre-v0.7.4 behavior.
+
    Derive 2-5 acceptance criteria from the brief. Each must be verifiable. Derive one or more Definition of Done strings as an array.
 
 5. Write the file to `<repo_root>/.cloverleaf/tasks/<allocated-id>.json`.
@@ -65,6 +75,7 @@ The user has invoked this skill with a brief. Your job: turn the brief into a st
 ## Rules
 
 - Do not guess at acceptance criteria. If the brief is too vague (e.g., "make it faster" with no target), ask the user a clarifying question before writing the file.
+- **`--rfc=<ID>` flag:** When the brief includes `--rfc=<RFC-ID>`, the task's `context.rfc` is populated from the on-disk RFC document (see step 4). Use this when scaffolding a standalone task linked to an RFC without a Plan parent — e.g., a hotfix-task pattern off an open RFC, as practiced by claw-crypto's CC-43/44 and CC-045..052. If `--rfc` is omitted, `context` is left empty; the task can be attached to a Plan later via Plan formation, or `context.rfc` can be edited in by hand.
 - **risk_class inference:** `risk_class` determines the Delivery pipeline (`"low"` → fast lane; `"high"` → full pipeline). Rules:
   1. If the user passed `--risk=high` or `--risk=low` as a flag on the skill invocation, honor it.
   2. Otherwise, set `risk_class: "high"` when the brief OR any acceptance criterion matches (case-insensitive) any of these keywords:

package/skills/cloverleaf-run-plan/SKILL.md

@@ -111,11 +111,23 @@ description: Autonomous DAG walker for Cloverleaf Plans. Given a PLAN-ID in stat
 
       Record the returned `session_id`, `worktree_path`, and `branch_name` in walk-state with `state: "running"`, `started_at: <now>`, `last_seq: 0`. Persist via `walk-state-write`.
 
-      Immediately after `mcp__claw-drive__start_session` returns, attach a Monitor tool stream for the new session:
+      Immediately after `mcp__claw-drive__start_session` returns, read the `notification_contract` from the session response and validate it:
+
+      ```bash
+      IDLE_AFTER=$(echo "$START_SESSION_RESPONSE" | jq -r '.notification_contract.idle_after_seconds // 600')
+      EXPECTED_TOKENS="DONE NEEDS-INPUT"
+      for tok in $EXPECTED_TOKENS; do
+        if ! echo "$START_SESSION_RESPONSE" | jq -e ".notification_contract.vocabulary | index(\"$tok\")" > /dev/null 2>&1; then
+          echo "WARNING: notification_contract.vocabulary missing expected token '$tok' — vocab drift detected" >&2
+        fi
+      done
+      ```
+
+      Then attach a Monitor tool stream for the new session:
 
       ```
       Monitor(
-        watch_command: "claw-drive watch <session_id> --since 0 --idle-after 600",
+        watch_command: "claw-drive watch <session_id> --since 0 --idle-after $IDLE_AFTER",
         persistent: true,
         timeout_ms: 3600000
       )
@@ -127,13 +139,13 @@ description: Autonomous DAG walker for Cloverleaf Plans. Given a PLAN-ID in stat
 
       ```
       Monitor(
-        watch_command: "claw-drive watch <session_id> --since <last_seq> --idle-after 600",
+        watch_command: "claw-drive watch <session_id> --since <last_seq> --idle-after $IDLE_AFTER",
         persistent: true,
         timeout_ms: 3600000
       )
       ```
 
-      The `--idle-after 600` flag instructs claw-drive to emit a synthetic `idle` event if a session produces no output for 600 seconds (10 minutes), enabling the walker to detect stalled sessions without polling.
+      The `--idle-after $IDLE_AFTER` flag instructs claw-drive to emit a synthetic `idle` event if a session produces no output for `$IDLE_AFTER` seconds, enabling the walker to detect stalled sessions without polling.
 
    d. **Handle events.** Dispatch each incoming Monitor event by type:
 
@@ -268,7 +280,48 @@ description: Autonomous DAG walker for Cloverleaf Plans. Given a PLAN-ID in stat
    - `awaiting_final_gate: [ ... ]` — user said `n`; re-invoke `/cloverleaf-merge <TASK-ID>` to retry.
    - `unreachable: [ ... ]` — descendants of escalated tasks.
 
-   If every task in the plan's `task_dag.nodes` has `state: "merged"`, print: "✓ Plan `<PLAN-ID>` complete."
+   **Plan completion (Standard 0.6.0+).** If every task in the plan's `task_dag.nodes` has `state: "merged"` AND the Plan's on-disk `status` is `"approved"`, advance the Plan to `completed`:
+
+   ```bash
+   cloverleaf-cli advance-plan <repo_root> <PLAN-ID> completed agent
+   git -C <repo_root> add .cloverleaf/plans/<PLAN-ID>.json .cloverleaf/events/
+   git -C <repo_root> commit -m "cloverleaf: plan <PLAN-ID> completed (all tasks merged)"
+   ```
+
+   This closes the previous state-sync gap where Plans whose tasks were all merged stayed at `status: "approved"` indefinitely. Skip the advance if the Plan is already at `completed` (idempotent re-runs of `/cloverleaf-run-plan` on a fully-merged plan must not error). After the advance, print: "✓ Plan `<PLAN-ID>` completed (status advanced approved → completed)."
+
+   If not every task is merged (some escalated or awaiting), do NOT advance the Plan. Print the partial-completion report from the bullets above.
+
+   **RFC auto-advance (Standard 0.6.0+).** Immediately after the Plan-advance commit lands, check whether the parent RFC can also advance to `completed`. Read the just-completed plan's `parent_rfc` (project + id), then scan all sibling plans of that RFC:
+
+   ```bash
+   PARENT_RFC_PROJECT=$(jq -r '.parent_rfc.project' <repo_root>/.cloverleaf/plans/<PLAN-ID>.json)
+   PARENT_RFC_ID=$(jq -r '.parent_rfc.id' <repo_root>/.cloverleaf/plans/<PLAN-ID>.json)
+   RFC_STATUS=$(jq -r '.status' <repo_root>/.cloverleaf/rfcs/"$PARENT_RFC_ID".json)
+
+   # Count sibling Plans still in-flight (drafting, gate-pending, or approved)
+   INFLIGHT=$(jq -s --arg proj "$PARENT_RFC_PROJECT" --arg id "$PARENT_RFC_ID" \
+     '[.[] | select(.parent_rfc.project == $proj and .parent_rfc.id == $id and (.status == "drafting" or .status == "gate-pending" or .status == "approved"))] | length' \
+     <repo_root>/.cloverleaf/plans/*.json)
+
+   # Count sibling Plans in completed (need at least one to advance)
+   COMPLETED=$(jq -s --arg proj "$PARENT_RFC_PROJECT" --arg id "$PARENT_RFC_ID" \
+     '[.[] | select(.parent_rfc.project == $proj and .parent_rfc.id == $id and .status == "completed")] | length' \
+     <repo_root>/.cloverleaf/plans/*.json)
+
+   if [ "$RFC_STATUS" = "approved" ] && [ "$INFLIGHT" = "0" ] && [ "$COMPLETED" != "0" ]; then
+     cloverleaf-cli advance-rfc <repo_root> "$PARENT_RFC_ID" completed agent
+     git -C <repo_root> add .cloverleaf/rfcs/"$PARENT_RFC_ID".json .cloverleaf/events/
+     git -C <repo_root> commit -m "cloverleaf: rfc $PARENT_RFC_ID completed ($COMPLETED sibling plans completed, 0 in-flight)"
+     echo "✓ RFC $PARENT_RFC_ID advanced approved → completed."
+   fi
+   ```
+
+   Auto-advance rules in plain language:
+   - Skip entirely if the RFC's `status` is not `approved` (already terminal, already abandoned, or somehow still pre-approval — leave it).
+   - Skip if any sibling Plan is still in-flight (`drafting`, `gate-pending`, or `approved`) — more work is pending on this RFC.
+   - Skip if no sibling Plan is `completed` (all `rejected`) — the RFC's decomposition was uniformly rejected; operator must decide whether to abandon or re-decompose.
+   - Otherwise advance the RFC to `completed`. Idempotent: the status guard makes re-runs safe.
 
    ## Next steps (release publishing)
 
@@ -342,3 +395,7 @@ The concrete policy JSON is the same one used during the CLV-16..CLV-20 dogfood
 - Final-gate drain is serial across tasks — one prompt, one decision.
 - The walker exits after the loop reports the final status; it does not auto-retry escalated tasks.
 - Scope-contested merges are escalated, never auto-resolved.
+
+## Notes
+
+**Vocab dependency.** The walker reads `notification_contract.vocabulary` from the `start_session` response advisorily — if the expected tokens (`DONE`, `NEEDS-INPUT`) are absent it warns to stderr but continues. The authoritative source of truth for which tokens Session B will emit is the SDK's `--driven-tokens` flag passed when claw-drive spawns the session. A mismatch between the contract and the actual flag signals a version skew between the claw-drive server and the reference-impl skill; upgrade both components together to keep them in sync.