aw-ecc 1.4.49 → 1.4.51

package/.codex/hooks/aw-post-tool-use.sh

@@ -0,0 +1,12 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Capture stdin before invoking the non-blocking telemetry sidecar.
+STDIN=$(cat)
+
+TELEMETRY_HOOK="$HOME/.aw-ecc/scripts/hooks/aw-usage-post-tool-use.js"
+if [[ -f "$TELEMETRY_HOOK" ]] && command -v node >/dev/null 2>&1; then
+  printf '%s' "$STDIN" | AW_HARNESS=codex node "$TELEMETRY_HOOK" >/dev/null 2>&1 || true
+fi
+
+exit 0

package/.codex/hooks/aw-pre-tool-use.sh

@@ -0,0 +1,6 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Reserved AW PreToolUse phase for Codex home routing.
+cat >/dev/null || true
+exit 0

package/.codex/hooks/aw-session-start.sh

@@ -0,0 +1,32 @@
+#!/usr/bin/env bash
+# aw-managed: codex-global-session-start
+set -euo pipefail
+
+# Capture stdin so we can feed it to both telemetry and the AW router delegate.
+STDIN=$(cat)
+
+# Fire session_start telemetry (non-blocking, all output suppressed).
+TELEMETRY_HOOK="$HOME/.aw-ecc/scripts/hooks/aw-usage-session-start.js"
+if [[ -f "$TELEMETRY_HOOK" ]] && command -v node >/dev/null 2>&1; then
+  printf '%s' "$STDIN" | AW_HARNESS=codex node "$TELEMETRY_HOOK" >/dev/null 2>&1 || true
+fi
+
+TARGETS=(
+  "$HOME/.aw_registry/platform/core/skills/using-aw-skills/hooks/session-start.sh"
+  "$HOME/.aw/.aw_registry/platform/core/skills/using-aw-skills/hooks/session-start.sh"
+)
+
+for target in "${TARGETS[@]}"; do
+  if [[ -f "$target" ]]; then
+    printf '%s' "$STDIN" | bash "$target"
+    exit $?
+  fi
+done
+
+CONTEXT="# AW Session Context
+
+WARNING: AW using-aw-skills hook not found in ~/.aw_registry. Run aw init or aw pull platform."
+
+JSON_CONTEXT=$(printf '%s' "$CONTEXT" | python3 -c 'import json, sys; print(json.dumps(sys.stdin.read()))')
+
+echo "{\"hookSpecificOutput\":{\"hookEventName\":\"SessionStart\",\"additionalContext\":${JSON_CONTEXT}}}"

package/.codex/hooks/aw-stop.sh

@@ -0,0 +1,12 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Capture stdin before invoking the non-blocking telemetry sidecar.
+STDIN=$(cat)
+
+TELEMETRY_HOOK="$HOME/.aw-ecc/scripts/hooks/aw-usage-stop.js"
+if [[ -f "$TELEMETRY_HOOK" ]] && command -v node >/dev/null 2>&1; then
+  printf '%s' "$STDIN" | AW_HARNESS=codex node "$TELEMETRY_HOOK" >/dev/null 2>&1 || true
+fi
+
+exit 0

package/.codex/hooks/aw-user-prompt-submit.sh

@@ -0,0 +1,18 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Capture stdin so we can feed it to both telemetry and the reminder delegate.
+STDIN=$(cat)
+
+TELEMETRY_HOOK="$HOME/.aw-ecc/scripts/hooks/aw-usage-prompt-submit.js"
+if [[ -f "$TELEMETRY_HOOK" ]] && command -v node >/dev/null 2>&1; then
+  printf '%s' "$STDIN" | AW_HARNESS=codex node "$TELEMETRY_HOOK" >/dev/null 2>&1 || true
+fi
+
+TARGET="$HOME/.aw-ecc/scripts/hooks/session-start-rules-context.sh"
+if [[ -f "$TARGET" ]]; then
+  printf '%s' "$STDIN" | bash "$TARGET"
+  exit $?
+fi
+
+exit 0

package/.codex/hooks.json

@@ -0,0 +1,62 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "*",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$HOME/.codex/hooks/aw-session-start.sh\""
+          }
+        ],
+        "description": "Load AW routing context at session start"
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$HOME/.codex/hooks/aw-user-prompt-submit.sh\""
+          }
+        ],
+        "description": "Emit Codex prompt telemetry and inject compact AW routing reminders on each prompt"
+      }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "*",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$HOME/.codex/hooks/aw-pre-tool-use.sh\""
+          }
+        ],
+        "description": "Reserved AW pre-tool-use phase for Codex home installs"
+      }
+    ],
+    "PostToolUse": [
+      {
+        "matcher": "*",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$HOME/.codex/hooks/aw-post-tool-use.sh\""
+          }
+        ],
+        "description": "Emit Codex post-tool-use telemetry for supported Bash-backed events"
+      }
+    ],
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$HOME/.codex/hooks/aw-stop.sh\""
+          }
+        ],
+        "description": "Emit Codex stop telemetry for response_completed events"
+      }
+    ]
+  }
+}

package/commands/plan.md

@@ -66,18 +66,19 @@ Record `html_companion_artifacts` in `state.json` with `source_path`, `html_path
 ## Execution Rules
 
 1. Classify the request into one primary mode first.
-2. Use `grill-with-docs` when the request is fuzzy, high-impact, domain-language-heavy, or likely to hide edge cases; do not make it a blanket blocker for small or already-clear plans.
-3. Use `to-prd` only when product scope must be frozen (`product` or `full` mode, or missing product assumptions); do not require a PRD for a technical request that is already well defined.
-4. Use `to-issues` before `tasks.md` when the work needs a vertical-slice breakdown; feed those slices into `aw-tasks` rather than publishing tracker issues by default.
-5. Operate in read-only planning mode until the artifacts are written.
-6. Default to single-scope planning.
-7. If the request is fuzzy, discovery-heavy, or too large for one spec, route internally through `aw-brainstorm` before technical planning.
-8. Use existing artifacts as inputs when they are already sufficient.
-9. Route approved technical direction through `aw-spec` before task planning.
-10. Route approved specs through `aw-tasks` when execution-ready tasks are missing or stale.
-11. When writing technical or task artifacts, make them concrete enough for build to proceed without re-planning file scope, validation, and task order.
-12. When writing `tasks.md`, always include an explicit `## Spec Brief` section and organize the work into explicit phases.
-13. Generate or explicitly record the HTML companion status before handoff.
+2. Always invoke `grill-with-docs` as the Decision Confidence Gate before writing artifacts, then follow its returned depth: proceed, ask one confirmation question, or run the full one-question-at-a-time interview.
+3. Treat deadline, launch, production, customer-visible, multi-repo, Auth/DNS/CI/CD/permissions, tenant isolation, rollback, ownership, or non-measurable acceptance criteria as full-interview triggers unless repo evidence fully resolves them.
+4. Use `to-prd` only when product scope must be frozen (`product` or `full` mode, or missing product assumptions); do not require a PRD for a technical request that is already well defined.
+5. Use `to-issues` before `tasks.md` when the work needs a vertical-slice breakdown; feed those slices into `aw-tasks` rather than publishing tracker issues by default.
+6. Operate in read-only planning mode until the artifacts are written.
+7. Default to single-scope planning.
+8. If the request is fuzzy, discovery-heavy, or too large for one spec, route internally through `aw-brainstorm` before technical planning.
+9. Use existing artifacts as inputs when they are already sufficient.
+10. Route approved technical direction through `aw-spec` before task planning.
+11. Route approved specs through `aw-tasks` when execution-ready tasks are missing or stale.
+12. When writing technical or task artifacts, make them concrete enough for build to proceed without re-planning file scope, validation, and task order.
+13. When writing `tasks.md`, always include an explicit `## Spec Brief` section and organize the work into explicit phases.
+14. Generate or explicitly record the HTML companion status before handoff.
 
 ## Planning Depth
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aw-ecc",
-  "version": "1.4.49",
+  "version": "1.4.51",
   "description": "GoHighLevel Agentic Workspace Engine — forked from Everything Claude Code (ecc-universal)",
   "keywords": [
     "claude-code",

package/skills/aw-plan/SKILL.md

@@ -42,7 +42,8 @@ This legacy heading maps to the detailed planning process below.
    In `product` mode, start by having a conversation with the user. Think of it like a PM sitting down with a stakeholder — ask about scope, target users, success criteria, edge cases, and constraints. Listen to the answers. Follow up on anything vague. Keep going until the problem is genuinely clear. Only then move to writing artifacts.
    In other modes, decide whether the request is already clear enough for direct planning or needs discovery first.
    For raw concepts or product-shaping work, load `idea-refine` before freezing the direction.
-   Use `grill-with-docs` when the request is fuzzy, domain-language-heavy, high-impact, or likely to hide edge cases. It is a precision tool, not a mandatory prelude for every plan.
+   Always route planning intake through `grill-with-docs` as the Decision Confidence Gate before writing artifacts.
+   Use adaptive depth: `clear` means state assumptions and proceed, `confirm` means ask one confirmation question, and `grill` means run the full one-question-at-a-time interview.
 4. Plan in dependency order.
    Perform an explicit architecture review before freezing the technical path.
    Name the key assumptions, constraints, risks, and mitigations instead of leaving them implied.
@@ -78,6 +79,27 @@ Use the smallest correct internal route:
 
 Do not collapse all of these responsibilities back into one vague planning pass.
 
+## Decision Confidence Gate
+
+Before writing planning artifacts, load `grill-with-docs` and use its returned depth to decide the next move.
+
+- If `grill-with-docs` returns `clear`, state the key assumptions it accepted and proceed.
+- If it returns `confirm`, ask its one recommended confirmation question and wait for the answer.
+- If it returns `grill`, continue its one-question-at-a-time interview before freezing the plan.
+
+Treat the request as full-interview depth when any trigger is present:
+
+- deadline, launch, production, customer-visible, or executive/high-impact wording
+- staging vs production, partial vs full rollout, rollback posture, or ownership is unclear
+- acceptance criteria are not measurable enough to prove the plan is done
+- terms are overloaded or likely to conflict with `CONTEXT.md`, ADRs, AW docs, repo docs, or code
+- the ask spans multiple repos, teams, services, environments, or external systems
+- Auth, DNS, CI/CD, permissions, tenant isolation, security, data migration, or public contract decisions are involved
+- existing AW docs or repo evidence can answer facts but not the user's intent, risk tolerance, or business priority
+
+Do not skip `grill-with-docs` only because code or PR evidence exists. Explore facts locally when possible, then ask the user only for the remaining decision.
+Do not let `/aw:plan` choose a shortcut before `grill-with-docs` runs.
+
 ## Planning Modes
 
 | Mode | Use when | Primary outputs |

package/skills/grill-with-docs/SKILL.md

@@ -1,17 +1,21 @@
 ---
 name: grill-with-docs
-description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
+description: Grilling session that challenges your plan against the existing domain model, AW planning context, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
 ---
 
 ## When To Use
 
-Use this inside planning when the problem is fuzzy, domain language is overloaded, acceptance criteria are under-specified, or existing docs/code may contradict the user's mental model.
+Use this inside every `/aw:plan` as the Decision Confidence Gate.
+Its default job is to classify planning intake as `clear`, `confirm`, or `grill`, not to force a long interview every time.
+
+High-impact requests should be grilled even when they sound clear on the surface if they hide decisions about staging vs production, rollout scope, ownership, Auth/DNS/CI/CD/permissions, tenant isolation, rollback, deadlines, or what counts as "live" or "done".
+For low-risk, single-scope technical work, return `clear` with assumptions and proceed. If exactly one assumption controls the outcome, return `confirm` and ask one question with a recommended answer. If the problem is fuzzy, high-impact, domain language is overloaded, acceptance criteria are under-specified, or existing AW docs, repo docs, or code may contradict the user's mental model, return `grill` and run the full interview.
 
 <what-to-do>
 
 Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
 
-Ask the questions one at a time, waiting for feedback on each question before continuing.
+In `grill` depth, ask questions one at a time, waiting for feedback on each question before continuing.
 
 If a question can be answered by exploring the codebase, explore the codebase instead.
 
@@ -21,7 +25,19 @@ If a question can be answered by exploring the codebase, explore the codebase in
 
 ## Domain awareness
 
-During codebase exploration, also look for existing documentation:
+During codebase exploration, also look for AW planning context and existing documentation.
+
+### AW feature context
+
+If `.aw_docs/` exists, resolve the active AW context before assuming the repo has no glossary or ADRs.
+
+1. Look for an explicit feature slug in the prompt, current branch, PR title, current files, or conversation. If present, inspect `.aw_docs/features/<slug>/`.
+2. If no explicit slug is present, search `.aw_docs/features/` for likely matches using the user's terms. Prefer folders with fresh `state.json`, `prd.md`, `design.md`, `spec.md`, `tasks.md`, `execution.md`, or `verification.md`.
+3. If multiple feature folders plausibly match, name the candidates and ask one short selection question before continuing.
+4. Read relevant AW feature files as planning memory. Markdown files remain the canonical agent-readable source; HTML sidecars are human-facing companions.
+5. Use `state.json`, plan files, PR links, git remotes, and changed paths to identify the target implementation repo or repos. In a workspace that contains multiple repos, do not treat the workspace container root as the domain root.
+
+AW docs do not replace domain docs. They tell you which feature and target repos to inspect. After resolving the AW feature context, inspect the target repo or bounded domain for `CONTEXT.md`, `CONTEXT-MAP.md`, and ADR folders.
 
 ### File structure
 
@@ -53,7 +69,9 @@ If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The ma
 │       └── docs/adr/
 ```
 
-Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+Create files lazily — only when you have something to write. If no `CONTEXT.md` exists in the resolved target repo or bounded context, create one when the first term is resolved. If no `docs/adr/` or `docs/adrs/` exists in that target context, create it when the first ADR is needed.
+
+Do not create `CONTEXT.md` or `docs/adr/` at a workspace container root just because they are missing there. If the root contains `.aw_docs/` plus multiple nested repos, first resolve the AW feature folder and target repo, then create or update docs in the target context.
 
 ## During the session
 

package/skills/grill-with-docs/evals/eval-aw-docs-context-root.md

@@ -0,0 +1,50 @@
+# Eval: AW Docs Context Root
+
+## Purpose
+
+Verify `grill-with-docs` resolves AW feature context before assuming root-level `CONTEXT.md` or `docs/adr/` are missing.
+
+## Scenario
+
+Workspace layout:
+
+```text
+/workspace/
+├── .aw_docs/
+│   └── features/
+│       └── teamofone-routines-agents-forward-plan/
+│           ├── spec.md
+│           ├── tasks.md
+│           └── state.json
+├── teamofone-monorepo/
+│   ├── package.json
+│   └── README.md
+└── platform-devtools-backend/
+    ├── package.json
+    └── README.md
+```
+
+No `CONTEXT.md`, `CONTEXT-MAP.md`, or `docs/adr/` exists at `/workspace/`.
+
+User asks:
+
+> Use grill-with-docs for the TeamOfOne routines and agents PRs. When we say Routine, is it saved configuration or executable workflow?
+
+## Expected Behavior
+
+The agent should:
+
+- Inspect `.aw_docs/features/teamofone-routines-agents-forward-plan/` as the active planning context.
+- Use `state.json`, `spec.md`, and `tasks.md` to identify likely target repos before declaring docs absent.
+- Avoid saying the workspace has no glossary solely because `/workspace/CONTEXT.md` and `/workspace/docs/adr/` are absent.
+- Avoid creating `/workspace/CONTEXT.md` or `/workspace/docs/adr/`.
+- Say that durable context docs should be created only in the resolved target repo or bounded context after terms are agreed.
+
+## Failure Modes
+
+The eval fails if the agent:
+
+- Treats `/workspace/` as the domain root without checking `.aw_docs/features/`.
+- Ignores the AW feature folder.
+- Creates or proposes root-level context docs in the workspace container.
+- Uses only generic `CONTEXT.md` / `docs/adr/` discovery language.

package/skills/using-aw-skills/SKILL.md

@@ -191,7 +191,7 @@ Load across stages when context applies: `incremental-implementation`, `context-
 
 | Skill | Load when |
 |---|---|
-| `grill-with-docs` | Inside `/aw:plan` when requirements, domain language, edge cases, or acceptance criteria are fuzzy enough that a guided interview would materially improve the artifact. |
+| `grill-with-docs` | Inside every `/aw:plan` as the Decision Confidence Gate. It classifies planning intake as `clear`, `confirm`, or `grill`: clear low-risk plans state assumptions and proceed, mostly-clear plans ask one confirmation question, and high-impact/fuzzy/hidden-decision/contradictory-docs plans run the full one-question-at-a-time grill. |
 | `to-prd` | Inside `/aw:plan` for product/full mode or when missing product assumptions must be frozen into `prd.md`; do not require it for already-clear technical plans. |
 | `to-issues` | Inside `/aw:plan` before `tasks.md` when a PRD/spec needs vertical tracer-bullet slices; remote issue publishing requires an explicit user request. |
 | `tdd` | Inside `/aw:build` as a companion to `tdd-workflow` when behavior-test, mocking, or tracer-bullet judgement needs more depth. |