@metasession.co/devaudit-cli 0.1.72 → 0.1.74

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metasession.co/devaudit-cli",
-  "version": "0.1.72",
+  "version": "0.1.74",
   "description": "DevAudit CLI — installs, syncs, and operates the Metasession SDLC across consumer projects.",
   "type": "module",
   "bin": {
@@ -33,7 +33,7 @@
   },
   "dependencies": {
     "@clack/prompts": "^0.8.2",
-    "@metasession.co/devaudit-plugin-sdk": "^0.1.72",
+    "@metasession.co/devaudit-plugin-sdk": "file:../plugin-sdk",
     "ajv": "^8.20.0",
     "commander": "^12.1.0",
     "consola": "^3.2.3",

package/sdlc/.claude/settings.local.json

@@ -0,0 +1,11 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(git init:*)",
+      "Bash(git add:*)",
+      "Bash(git branch:*)",
+      "Bash(git commit:*)",
+      "Bash(gh repo:*)"
+    ]
+  }
+}

package/sdlc/ai-rules/INSTRUCTIONS-SDLC.md

@@ -36,6 +36,36 @@ This prompt is **mandatory and structural** — it is not advisory. The `sdlc-im
 
 The only exception: if the user's request is clearly housekeeping ("bump a dep", "fix a typo", "update docs") and does not involve `feat`/`fix`/`refactor`/`perf` commit types, skip the prompt and proceed directly.
 
+### Anti-pattern: manually walking through SDLC stages instead of invoking the skill (devaudit-installer#199)
+
+The most common failure mode for this rule is **not skipping the prompt entirely** — it is **prompting (or being told to use the skill) and then manually reading the SDLC workflow files and walking through the steps yourself** instead of invoking the `sdlc-implementer` skill. The skill exists to orchestrate this. Manually reading `SDLC/1-plan-requirement.md`, `SDLC/2-implement-and-test.md`, etc. and executing their steps by hand is the exact failure mode this rule exists to prevent.
+
+**Self-check — if you find yourself doing any of these, STOP:**
+- Reading `SDLC/1-plan-requirement.md` directly instead of invoking the skill
+- Manually classifying risk, writing an implementation plan, or updating the RTM by hand instead of letting the skill drive it
+- Walking through Stage 1 → Stage 2 → Stage 3 sequentially by reading each workflow file
+- Saying "let me read the SDLC workflow files" or "let me follow the SDLC process" without invoking the skill
+
+**When you catch yourself:** Stop immediately. Invoke the skill with `Skill(name: "sdlc-implementer", …)`. Do not attempt to continue the manual walkthrough — the skill will re-read state and resume correctly.
+
+This anti-pattern is the same class of bug as #132 (e2e delegation bypass): the agent has a purpose-built tool and defaults to hand-rolling the procedure it automates. The skill is the tool. Use it.
+
+### Driver clarity — always state who is driving (devaudit-installer#199)
+
+The operator must be able to tell at a glance whether they need to act or whether the agent is handling it. **Every substantive response during SDLC work MUST open with a driver tag** on the first line, before any other content:
+
+- **`[Agent driving]`** — the agent is auto-continuing; no human action needed right now. The operator can look away.
+- **`[Operator driving]`** — the agent has halted; the human must do something (review, approve, merge, answer a question). State the specific action needed.
+- **`[Blocked]`** — something failed and the agent cannot proceed. State the blocker and the operator action needed to unblock.
+
+Rules:
+- The tag is the **first thing** in the response — no preamble, no acknowledgement, no "Great question" before it.
+- If the driver changes mid-response (e.g. the agent was driving, hits a gate failure, and halts), the tag at the top of the response reflects the **final** state. If the agent stops mid-work, the tag is `[Operator driving]` or `[Blocked]`.
+- The tag is mandatory for any response that does work, reports status, or hands off. Skip it only for pure chitchat or one-word confirmations.
+- The tag works alongside the LAST/NEXT sticky convention — the tag says *who* is driving right now; the sticky says *what* just happened and *what* is next.
+
+**Why this exists:** Without an explicit driver tag, the operator cannot distinguish "the agent is working and I can wait" from "the agent stopped and I need to act" without reading the entire response. That ambiguity is the root cause of both false-waits (operator thinks the agent is working when it has halted) and false-stops (operator thinks they need to act when the agent is auto-continuing).
+
 ### Before ANY Code Change
 
 1. If the user has NOT been prompted for `sdlc-implementer` and the change is not trivial housekeeping, stop and run the mandatory prompt above before continuing.

package/sdlc/ai-rules/SDLC_RULES.md

@@ -17,6 +17,51 @@ This project contains detailed SDLC workflow files in its `SDLC/` directory (cop
 
 Tier 1 reference docs (Test_Policy.md, Test_Strategy.md, Test_Architecture.md, Periodic_Security_Review_Schedule.md) may also be in `SDLC/` or in the DevAudit repository.
 
+## CRITICAL: `sdlc-implementer` prompt before implementation (devaudit-installer#199)
+
+When the user requests implementation of an issue (e.g. "implement issue #N", "fix issue #N", "do issue #N", "implement #N"), you MUST prompt before writing any code:
+
+> Implementing #N using sdlc-implementer, can I proceed?
+
+Wait for the user's yes/no response. Do NOT begin implementation until they answer.
+
+- **YES** → invoke the `sdlc-implementer` skill immediately. The skill drives Phase 0 (triage) through Phase 4 (PR + UAT review).
+- **NO** → proceed with manual implementation outside the skill. The user has explicitly opted out; respect their choice and do not ask again for the same issue.
+
+This prompt is **mandatory and structural** — it is not advisory. Skipping the prompt and jumping straight into code is the same class of inertia-trap bug as #132 (e2e delegation bypass).
+
+The only exception: if the user's request is clearly housekeeping ("bump a dep", "fix a typo", "update docs") and does not involve `feat`/`fix`/`refactor`/`perf` commit types, skip the prompt and proceed directly.
+
+### Anti-pattern: manually walking through SDLC stages instead of invoking the skill
+
+The most common failure mode is **prompting (or being told to use the skill) and then manually reading the SDLC workflow files and walking through the steps yourself** instead of invoking the `sdlc-implementer` skill. The skill exists to orchestrate this. Manually reading `SDLC/1-plan-requirement.md`, `SDLC/2-implement-and-test.md`, etc. and executing their steps by hand is the exact failure mode this rule exists to prevent.
+
+**Self-check — if you find yourself doing any of these, STOP:**
+- Reading `SDLC/1-plan-requirement.md` directly instead of invoking the skill
+- Manually classifying risk, writing an implementation plan, or updating the RTM by hand instead of letting the skill drive it
+- Walking through Stage 1 → Stage 2 → Stage 3 sequentially by reading each workflow file
+- Saying "let me read the SDLC workflow files" or "let me follow the SDLC process" without invoking the skill
+
+**When you catch yourself:** Stop immediately. Invoke the skill with `Skill(name: "sdlc-implementer", …)`. Do not attempt to continue the manual walkthrough — the skill will re-read state and resume correctly.
+
+## Driver clarity — always state who is driving (devaudit-installer#199)
+
+The operator must be able to tell at a glance whether they need to act or whether the agent is handling it. **Every substantive response during SDLC work MUST open with a driver tag** on the first line, before any other content:
+
+- **`[Agent driving]`** — the agent is auto-continuing; no human action needed right now. The operator can look away.
+- **`[Operator driving]`** — the agent has halted; the human must do something (review, approve, merge, answer a question). State the specific action needed.
+- **`[Blocked]`** — something failed and the agent cannot proceed. State the blocker and the operator action needed to unblock.
+
+Rules:
+- The tag is the **first thing** in the response — no preamble, no acknowledgement, no "Great question" before it.
+- If the driver changes mid-response (e.g. the agent was driving, hits a gate failure, and halts), the tag at the top of the response reflects the **final** state. If the agent stops mid-work, the tag is `[Operator driving]` or `[Blocked]`.
+- The tag is mandatory for any response that does work, reports status, or hands off. Skip it only for pure chitchat or one-word confirmations.
+- The tag works alongside the LAST/NEXT sticky convention — the tag says *who* is driving right now; the sticky says *what* just happened and *what* is next.
+
+**Why this exists:** Without an explicit driver tag, the operator cannot distinguish "the agent is working and I can wait" from "the agent stopped and I need to act" without reading the entire response. That ambiguity is the root cause of both false-waits (operator thinks the agent is working when it has halted) and false-stops (operator thinks they need to act when the agent is auto-continuing).
+
+---
+
 ## CRITICAL: Before Writing Any Code
 
 Before implementing ANY change (feature, fix, refactor, or enhancement), you MUST complete these checks:

package/sdlc/ai-rules/claude/CLAUDE.md

@@ -21,13 +21,55 @@ When a workflow step requires detailed commands or templates, **read the full wo
 
 Tier 1 reference documents (policy, strategy, architecture) are also in `SDLC/` if present, or in the DevAudit repository at `sdlc/files/`.
 
+### MANDATORY: `sdlc-implementer` prompt before implementation (devaudit-installer#199)
+
+When the user requests implementation of an issue (e.g. "implement issue #N", "fix issue #N", "do issue #N", "implement #N"), you MUST prompt before writing any code:
+
+> Implementing #N using sdlc-implementer, can I proceed?
+
+Wait for the user's yes/no response. Do NOT begin implementation until they answer.
+
+- **YES** → invoke the `sdlc-implementer` skill immediately. The skill drives Phase 0 (triage) through Phase 4 (PR + UAT review).
+- **NO** → proceed with manual implementation outside the skill. The user has explicitly opted out; respect their choice and do not ask again for the same issue.
+
+This prompt is **mandatory and structural** — it is not advisory. Skipping the prompt and jumping straight into code is the same class of inertia-trap bug as #132 (e2e delegation bypass).
+
+The only exception: if the user's request is clearly housekeeping ("bump a dep", "fix a typo", "update docs") and does not involve `feat`/`fix`/`refactor`/`perf` commit types, skip the prompt and proceed directly.
+
+### Anti-pattern: manually walking through SDLC stages instead of invoking the skill
+
+The most common failure mode is **prompting (or being told to use the skill) and then manually reading the SDLC workflow files and walking through the steps yourself** instead of invoking the `sdlc-implementer` skill. The skill exists to orchestrate this. Manually reading `SDLC/1-plan-requirement.md`, `SDLC/2-implement-and-test.md`, etc. and executing their steps by hand is the exact failure mode this rule exists to prevent.
+
+**Self-check — if you find yourself doing any of these, STOP:**
+- Reading `SDLC/1-plan-requirement.md` directly instead of invoking the skill
+- Manually classifying risk, writing an implementation plan, or updating the RTM by hand instead of letting the skill drive it
+- Walking through Stage 1 → Stage 2 → Stage 3 sequentially by reading each workflow file
+- Saying "let me read the SDLC workflow files" or "let me follow the SDLC process" without invoking the skill
+
+**When you catch yourself:** Stop immediately. Invoke the skill with `Skill(name: "sdlc-implementer", …)`. Do not attempt to continue the manual walkthrough — the skill will re-read state and resume correctly.
+
+### Driver clarity — always state who is driving (devaudit-installer#199)
+
+The operator must be able to tell at a glance whether they need to act or whether the agent is handling it. **Every substantive response during SDLC work MUST open with a driver tag** on the first line, before any other content:
+
+- **`[Agent driving]`** — the agent is auto-continuing; no human action needed right now. The operator can look away.
+- **`[Operator driving]`** — the agent has halted; the human must do something (review, approve, merge, answer a question). State the specific action needed.
+- **`[Blocked]`** — something failed and the agent cannot proceed. State the blocker and the operator action needed to unblock.
+
+Rules:
+- The tag is the **first thing** in the response — no preamble, no acknowledgement, no "Great question" before it.
+- If the driver changes mid-response (e.g. the agent was driving, hits a gate failure, and halts), the tag at the top of the response reflects the **final** state. If the agent stops mid-work, the tag is `[Operator driving]` or `[Blocked]`.
+- The tag is mandatory for any response that does work, reports status, or hands off. Skip it only for pure chitchat or one-word confirmations.
+- The tag works alongside the LAST/NEXT sticky convention — the tag says *who* is driving right now; the sticky says *what* just happened and *what* is next.
+
 ### Before ANY Code Change
 
-1. Ask: **"Which GitHub Issue is this for?"** before writing code. Fetch it with `gh issue view NNN`.
-2. If no issue exists: ask if one should be created. When creating via `gh issue create`, ALWAYS append the SDLC checklist to the body (see below).
-3. If new requirement needed: **read `SDLC/1-plan-requirement.md`** and follow it to create RTM entry (with issue reference), evidence directory, and test-scope.md BEFORE implementing.
-4. If trivial (typo/formatting): proceed without requirement but use conventional commit format.
-5. Verify `develop` branch: `git branch --show-current` — never implement on `main`.
+1. If the user has NOT been prompted for `sdlc-implementer` and the change is not trivial housekeeping, stop and run the mandatory prompt above before continuing.
+2. Ask: **"Which GitHub Issue is this for?"** before writing code. Fetch it with `gh issue view NNN`.
+3. If no issue exists: ask if one should be created. When creating via `gh issue create`, ALWAYS append the SDLC checklist to the body (see below).
+4. If new requirement needed: **read `SDLC/1-plan-requirement.md`** and follow it to create RTM entry (with issue reference), evidence directory, and test-scope.md BEFORE implementing.
+5. If trivial (typo/formatting): proceed without requirement but use conventional commit format.
+6. Verify `develop` branch: `git branch --show-current` — never implement on `main`.
 
 ### For ALL Code Changes (including bug fixes)
 

package/sdlc/ai-rules/windsurf/.windsurfrules

@@ -15,13 +15,55 @@ Detailed workflow instructions are in this project's `SDLC/` directory. Read the
 
 When a workflow step requires detailed commands or templates, read the full workflow file rather than relying on the summary below.
 
+### MANDATORY: `sdlc-implementer` prompt before implementation (devaudit-installer#199)
+
+When the user requests implementation of an issue (e.g. "implement issue #N", "fix issue #N", "do issue #N", "implement #N"), you MUST prompt before writing any code:
+
+> Implementing #N using sdlc-implementer, can I proceed?
+
+Wait for the user's yes/no response. Do NOT begin implementation until they answer.
+
+- **YES** → invoke the `sdlc-implementer` skill immediately. The skill drives Phase 0 (triage) through Phase 4 (PR + UAT review).
+- **NO** → proceed with manual implementation outside the skill. The user has explicitly opted out; respect their choice and do not ask again for the same issue.
+
+This prompt is **mandatory and structural** — it is not advisory. Skipping the prompt and jumping straight into code is the same class of inertia-trap bug as #132 (e2e delegation bypass).
+
+The only exception: if the user's request is clearly housekeeping ("bump a dep", "fix a typo", "update docs") and does not involve `feat`/`fix`/`refactor`/`perf` commit types, skip the prompt and proceed directly.
+
+### Anti-pattern: manually walking through SDLC stages instead of invoking the skill
+
+The most common failure mode is **prompting (or being told to use the skill) and then manually reading the SDLC workflow files and walking through the steps yourself** instead of invoking the `sdlc-implementer` skill. The skill exists to orchestrate this. Manually reading `SDLC/1-plan-requirement.md`, `SDLC/2-implement-and-test.md`, etc. and executing their steps by hand is the exact failure mode this rule exists to prevent.
+
+**Self-check — if you find yourself doing any of these, STOP:**
+- Reading `SDLC/1-plan-requirement.md` directly instead of invoking the skill
+- Manually classifying risk, writing an implementation plan, or updating the RTM by hand instead of letting the skill drive it
+- Walking through Stage 1 → Stage 2 → Stage 3 sequentially by reading each workflow file
+- Saying "let me read the SDLC workflow files" or "let me follow the SDLC process" without invoking the skill
+
+**When you catch yourself:** Stop immediately. Invoke the skill with `Skill(name: "sdlc-implementer", …)`. Do not attempt to continue the manual walkthrough — the skill will re-read state and resume correctly.
+
+### Driver clarity — always state who is driving (devaudit-installer#199)
+
+The operator must be able to tell at a glance whether they need to act or whether the agent is handling it. **Every substantive response during SDLC work MUST open with a driver tag** on the first line, before any other content:
+
+- **`[Agent driving]`** — the agent is auto-continuing; no human action needed right now. The operator can look away.
+- **`[Operator driving]`** — the agent has halted; the human must do something (review, approve, merge, answer a question). State the specific action needed.
+- **`[Blocked]`** — something failed and the agent cannot proceed. State the blocker and the operator action needed to unblock.
+
+Rules:
+- The tag is the **first thing** in the response — no preamble, no acknowledgement, no "Great question" before it.
+- If the driver changes mid-response (e.g. the agent was driving, hits a gate failure, and halts), the tag at the top of the response reflects the **final** state. If the agent stops mid-work, the tag is `[Operator driving]` or `[Blocked]`.
+- The tag is mandatory for any response that does work, reports status, or hands off. Skip it only for pure chitchat or one-word confirmations.
+- The tag works alongside the LAST/NEXT sticky convention — the tag says *who* is driving right now; the sticky says *what* just happened and *what* is next.
+
 ### Before ANY Code Change
 
-1. Ask: "Which GitHub Issue is this for?" before writing code. Fetch it with `gh issue view NNN`.
-2. If no issue exists: ask if one should be created. When creating via `gh issue create`, ALWAYS append the SDLC checklist to the body (see below).
-3. If new requirement needed: read `SDLC/1-plan-requirement.md` and follow it BEFORE implementing.
-4. If trivial (typo/formatting): proceed without requirement but use conventional commit format.
-5. Verify `develop` branch: `git branch --show-current` — never implement on `main`.
+1. If the user has NOT been prompted for `sdlc-implementer` and the change is not trivial housekeeping, stop and run the mandatory prompt above before continuing.
+2. Ask: "Which GitHub Issue is this for?" before writing code. Fetch it with `gh issue view NNN`.
+3. If no issue exists: ask if one should be created. When creating via `gh issue create`, ALWAYS append the SDLC checklist to the body (see below).
+4. If new requirement needed: read `SDLC/1-plan-requirement.md` and follow it BEFORE implementing.
+5. If trivial (typo/formatting): proceed without requirement but use conventional commit format.
+6. Verify `develop` branch: `git branch --show-current` — never implement on `main`.
 
 ### For ALL Code Changes (including bug fixes)
 

package/sdlc/files/_common/skills/sdlc-implementer/SKILL.md

@@ -206,14 +206,24 @@ NEXT: Done — close issue + retire feature branch (sdlc-implementer halts)
 
 ### 2. In-chat LAST/NEXT line (Claude Code surface)
 
-Lead every substantive turn with the same two-line shape so the operator can `Ctrl-F NEXT:` in the chat transcript to find the current pointer without re-reading:
+Lead every substantive turn with a driver tag on the **first line**, then the two-line LAST/NEXT shape so the operator can `Ctrl-F NEXT:` in the chat transcript to find the current pointer without re-reading:
 
 ```
+[Agent driving]   — or —   [Operator driving]   — or —   [Blocked]
+
 **LAST:** <one sentence>
 **NEXT:** <one sentence with actor>
 ```
 
-Skip it for trivial turns (acknowledging a "merged" / one-line confirmations / chitchat). It's for SDLC work, not every message. The two surfaces (sticky comment + chat line) should always agree — if they diverge, the comment is canonical (it's what the operator scrolling the issue sees).
+The driver tag is mandatory and comes **before** the LAST/NEXT lines:
+
+- **`[Agent driving]`** — the skill is auto-continuing; no human action needed right now. The operator can look away.
+- **`[Operator driving]`** — the skill has halted; the human must do something (review, approve, merge, answer a question). The NEXT line states the specific action needed.
+- **`[Blocked]`** — something failed and the skill cannot proceed. State the blocker and the operator action needed to unblock.
+
+The tag reflects the **final** state of the response — if the skill was driving but hits a halt mid-turn, the tag is `[Operator driving]` or `[Blocked]`.
+
+Skip the tag and LAST/NEXT for trivial turns (acknowledging a "merged" / one-line confirmations / chitchat). It's for SDLC work, not every message. The two surfaces (sticky comment + chat line) should always agree — if they diverge, the comment is canonical (it's what the operator scrolling the issue sees).
 
 ### When to update
 

package/sdlc/files/stacks/node/hooks/pre-push

@@ -1,4 +1,4 @@
-#!/usr/bin/env bash
+#!/bin/sh
 # Husky pre-push hook — fast gates + E2E evidence + skill-invocation sentinel + compliance validator.
 #
 # Runs four checks before allowing a push:
@@ -13,7 +13,7 @@
 #
 # Install: cp this file to .husky/pre-push && chmod +x .husky/pre-push
 
-set -euo pipefail
+set -eu
 
 # ── 1. TypeScript check ──────────────────────────────────────────────
 echo "Pre-push: running TypeScript check..."
@@ -35,9 +35,10 @@ INTEGRATION_BRANCH=$(jq -r '.integration_branch // "develop"' sdlc-config.json 2
 # Read stdin to get the pushed refs (husky pre-push protocol)
 while read -r local_ref local_sha remote_ref remote_sha; do
   # Check if pushing to the integration branch
-  if [[ "$remote_ref" != *"refs/heads/$INTEGRATION_BRANCH" ]]; then
-    continue
-  fi
+  case "$remote_ref" in
+    *"refs/heads/$INTEGRATION_BRANCH") ;;
+    *) continue ;;
+  esac
 
   # Determine the commit range being pushed
   if [ "$remote_sha" = "0000000000000000000000000000000000000000" ]; then
@@ -79,9 +80,10 @@ TRACKED_TYPES='^(feat|fix|refactor|perf)(\(.+\))?!?:'
 HAS_TRACKED=false
 
 while read -r local_ref local_sha remote_ref remote_sha; do
-  if [[ "$remote_ref" != *"refs/heads/$INTEGRATION_BRANCH" ]]; then
-    continue
-  fi
+  case "$remote_ref" in
+    *"refs/heads/$INTEGRATION_BRANCH") ;;
+    *) continue ;;
+  esac
   if [ "$remote_sha" = "0000000000000000000000000000000000000000" ]; then
     RANGE="$local_sha"
   else