kodelyth-ecc 1.5.8 → 1.5.10

package/CHANGELOG.md

@@ -2,6 +2,29 @@
 
 All notable changes to Kodelyth ECC are documented here.
 
+## v1.5.10 — Fix install crash on macOS bash 3.2 (May 2026)
+
+### Bug Fix
+
+- **`install.sh` crashes after Rules (common) on `claude-home` target** — `set -euo pipefail` + bash 3.2 (macOS default) treats an empty array `"${LANGUAGE_MODULES[@]}"` as an unbound variable and exits. Fixed by using the bash 3.2-safe empty-array expansion `"${LANGUAGE_MODULES[@]+"${LANGUAGE_MODULES[@]}"}"`, matching the pattern already correctly used for the JSON install state on line 430. Users who install without any `--profile` or language flags (the majority) were affected.
+
+---
+
+## v1.5.9 — Intent routing for all 5 parallel commands (May 2026)
+
+### Bug Fix / Feature
+
+- **5 parallel commands now fully routable by natural language** — `/security-audit`, `/pre-release`, `/debug-blitz`, `/refactor-sprint`, and `/onboard` were added in v1.5.4 but never added to `rules/common/agent-intent-routing.md`. Users had to type the exact command name. Now the AI auto-routes to them from plain descriptions:
+  - "been stuck on this bug for 2 days" → `/debug-blitz`
+  - "cutting v2 today, last check" → `/pre-release`
+  - "is my app secure? check everything" → `/security-audit`
+  - "clean up this whole module, add types and tests" → `/refactor-sprint`
+  - "I just joined this team, where do I start?" → `/onboard`
+- Each command now has a full routing section with signal table, key rule, counter-signals, and agent list.
+- 10 new examples added to the routing examples table.
+
+---
+
 ## v1.5.8 — README and SVG refresh (May 2026)
 
 ### Changes

package/VERSION

@@ -1 +1 @@
-1.5.8
+1.5.10

package/install.sh

@@ -363,7 +363,7 @@ case "$TARGET" in
       cp -r "$SCRIPT_DIR/rules/common"/. "$RULES_DEST/"
       echo -e "  ${GREEN}✓${RESET} Rules (common) ${BLUE}(→ $RULES_DEST)${RESET}"
     fi
-    for lang in "${LANGUAGE_MODULES[@]}"; do
+    for lang in "${LANGUAGE_MODULES[@]+"${LANGUAGE_MODULES[@]}"}"; do
       if [[ -d "$SCRIPT_DIR/rules/$lang" ]]; then
         mkdir -p "$RULES_DEST/$lang"
         cp -r "$SCRIPT_DIR/rules/$lang"/. "$RULES_DEST/$lang/"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kodelyth-ecc",
-  "version": "1.5.8",
+  "version": "1.5.10",
   "description": "Production-grade AI coding toolkit — 62 agents, 188 skills, 90 commands, parallel multi-agent commands, semantic intent routing, self-learning memory. Works with Claude Code, Windsurf, Cursor, Codex, Antigravity, and OpenCode.",
   "author": "Kodelyth <github.com/sifxprime>",
   "license": "MIT",

package/rules/common/agent-intent-routing.md

@@ -428,6 +428,98 @@ Route to `/team-review` — fires `code-reviewer` + `security-reviewer` + `perfo
 
 ---
 
+### `/security-audit` — Full parallel security sweep
+
+Trigger when the user is worried about security across the whole project, not just one file. Also trigger before any public launch, API exposure, or when secrets/auth/dependencies are mentioned together.
+
+| Signal | Real human phrasing |
+|---|---|
+| Full security concern | "is my app secure?", "security audit", "check my security", "is there anything insecure?", "run a security check" |
+| Pre-launch security | "before I go public", "about to expose this API", "launching soon, any security issues?" |
+| Dependency worry | "are my deps safe?", "any vulnerable packages?", "CVEs in my dependencies?" |
+| Auth concern | "is my auth secure?", "is my login safe?", "JWT/OAuth/session security" combined with dep or API mention |
+| Multiple security angles | User mentions secrets AND API keys AND dependencies together — all three need sweeping |
+
+**Key rule:** Single security concern on one file → `security-reviewer`. Full project sweep or multiple security vectors at once → `/security-audit`.
+
+**Counter-signals (do NOT route here):** Single endpoint with a specific injection concern → `security-reviewer`. Dependency-only question → `dependency-doctor`.
+
+Route to `/security-audit` — fires `security-reviewer` + `dependency-doctor` + `api-guardian` simultaneously.
+
+---
+
+### `/pre-release` — Ship-readiness parallel check
+
+Trigger when the user is about to cut a release, tag a version, or deploy to production and wants confidence everything is correct. Also trigger when they mention "release" + "check" or "ready to ship" + version number.
+
+| Signal | Real human phrasing |
+|---|---|
+| About to release | "ready to cut v2?", "about to release", "cutting a release", "tagging v1.0", "shipping today" |
+| Release checklist | "what do I need before releasing?", "release checklist", "anything missing before v2?" |
+| Version confidence | "is v3 ready?", "can I ship this version?", "pre-release check for 2.0" |
+| Final sanity check | "last check before I push to prod", "final review before release", "one more look before shipping" |
+| Combined signals | User mentions semver + "ready" or "deploy" + "safe" together |
+
+**Key rule:** General "is this ready" with no version/release framing → `/team-review`. Explicit release or version cut → `/pre-release`.
+
+Route to `/pre-release` — fires `release-captain` + `security-reviewer` + `code-reviewer` simultaneously.
+
+---
+
+### `/debug-blitz` — Triple-agent parallel debug for stubborn bugs
+
+Trigger when a bug has resisted normal debugging, when the user is frustrated after trying multiple things, or when the problem could be in multiple layers (code + env + hidden failure).
+
+| Signal | Real human phrasing |
+|---|---|
+| Persistent bug | "I've been fighting this bug for hours", "can't figure this out", "nothing is working", "tried everything" |
+| Multi-layer problem | "works locally not in CI", "works on my machine", "only fails in prod", "sometimes fails" |
+| Hidden failure | "no error but wrong behavior", "silently failing", "something is wrong but I don't know what" |
+| Environment suspicion | "is it my env?", "could it be a config issue?", "not sure if it's the code or environment" |
+| Frustration signal | "I give up", "losing my mind", "this is driving me crazy", "been stuck for X hours/days" |
+
+**Key rule:** First-time bug report → `debug-detective`. Persistent, multi-attempt, or multi-layer bug → `/debug-blitz`. Emotion of long frustration is a strong signal for blitz.
+
+Route to `/debug-blitz` — fires `debug-detective` + `silent-failure-hunter` + `env-debugger` simultaneously.
+
+---
+
+### `/refactor-sprint` — Full parallel refactor + type + test pass
+
+Trigger when the user wants a comprehensive cleanup of existing code — not just one function, but a module, file, or system. Also trigger when multiple quality concerns are mentioned together (readability + types + tests).
+
+| Signal | Real human phrasing |
+|---|---|
+| Big cleanup | "refactor this module", "clean up this whole file", "this code is a mess", "technical debt cleanup" |
+| Multi-concern quality | "improve quality, types, and add tests", "make this cleaner and add coverage", "full cleanup" |
+| Code health | "code is getting hard to maintain", "too much complexity", "needs a full cleanup", "legacy code overhaul" |
+| Combined refactor | "refactor + add types + write tests" — three concerns together always means blitz |
+| Pre-hire prep | "cleaning up before the new dev joins", "making this more readable for the team" |
+
+**Key rule:** Cleanup of one function → `refactor-cleaner`. Cleanup of a whole module/file with types and tests → `/refactor-sprint`.
+
+Route to `/refactor-sprint` — fires `refactor-cleaner` + `code-simplifier` + `type-design-analyzer` + `tdd-guide` simultaneously.
+
+---
+
+### `/onboard` — New-joiner parallel codebase onboarding
+
+Trigger when someone is new to a codebase and needs to understand it — either a new team member, or the user themselves joining a project they didn't write.
+
+| Signal | Real human phrasing |
+|---|---|
+| New to codebase | "I just joined the team", "new to this project", "inherited this codebase", "taking over this repo" |
+| Explore unfamiliar code | "never seen this code before", "trying to understand this project", "where do I even start?" |
+| Onboarding docs | "we need onboarding docs", "no documentation for new devs", "new dev joining, need to explain the codebase" |
+| Architecture understanding | "what does this system do?", "explain the architecture to me", "how does all of this fit together?" |
+| Ramp-up request | "help me get up to speed", "ramp me up on this", "what should I know about this codebase?" |
+
+**Key rule:** Single "explain this function" → `code-explorer`. Full codebase orientation or onboarding a new person → `/onboard`.
+
+Route to `/onboard` — fires `code-explorer` + `architect` + `doc-updater` simultaneously.
+
+---
+
 ### `/lessons` — Project lessons management
 
 Trigger when the user references project rules, preferences, corrections, or past instructions. Also trigger proactively at session start if `tasks/lessons.md` exists in the project root.
@@ -501,6 +593,16 @@ When the user's request spans multiple concerns, name the parallel agents and ex
 | "review my code before I deploy" | `/team-review` | Pre-release, full scope |
 | "is my project ready to ship?" | `/team-review` | Readiness check |
 | "full audit before we release v2" | `/team-review` | Explicit full audit |
+| "is my app secure? check everything" | `/security-audit` | Full security sweep |
+| "any CVEs in my deps?" | `/security-audit` | Dependency + security combo |
+| "cutting v2 today, last check" | `/pre-release` | Release + confidence combo |
+| "anything missing before I tag 1.0?" | `/pre-release` | Release checklist signal |
+| "been stuck on this bug for 2 days" | `/debug-blitz` | Persistent frustration = blitz |
+| "works locally not in prod" | `/debug-blitz` | Multi-layer problem |
+| "clean up this whole module, add types and tests" | `/refactor-sprint` | Multi-concern quality |
+| "this code is a mess, full cleanup needed" | `/refactor-sprint` | Technical debt + scope |
+| "I just joined this team, where do I start?" | `/onboard` | New-joiner onboarding |
+| "inherited this codebase, help me understand it" | `/onboard` | Unfamiliar codebase |
 | "remember we always use pnpm here" | `/lessons` | Preference to encode |
 | "what rules do we follow in this project?" | `/lessons` | Load lessons |
 | "from now on never use var" | `/lessons` | Rule to save |