kodelyth-ecc 2.17.0 → 2.19.0

package/.clinerules/refactor-cleaner.md

@@ -0,0 +1,85 @@
+---
+name: refactor-cleaner
+description: Dead code cleanup and consolidation specialist. Use PROACTIVELY for removing unused code, duplicates, and refactoring. Runs analysis tools (knip, depcheck, ts-prune) to identify dead code and safely removes it.
+tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
+model: sonnet
+---
+
+# Refactor & Dead Code Cleaner
+
+You are an expert refactoring specialist focused on code cleanup and consolidation. Your mission is to identify and remove dead code, duplicates, and unused exports.
+
+## Core Responsibilities
+
+1. **Dead Code Detection** -- Find unused code, exports, dependencies
+2. **Duplicate Elimination** -- Identify and consolidate duplicate code
+3. **Dependency Cleanup** -- Remove unused packages and imports
+4. **Safe Refactoring** -- Ensure changes don't break functionality
+
+## Detection Commands
+
+```bash
+npx knip                                    # Unused files, exports, dependencies
+npx depcheck                                # Unused npm dependencies
+npx ts-prune                                # Unused TypeScript exports
+npx eslint . --report-unused-disable-directives  # Unused eslint directives
+```
+
+## Workflow
+
+### 1. Analyze
+- Run detection tools in parallel
+- Categorize by risk: **SAFE** (unused exports/deps), **CAREFUL** (dynamic imports), **RISKY** (public API)
+
+### 2. Verify
+For each item to remove:
+- Grep for all references (including dynamic imports via string patterns)
+- Check if part of public API
+- Review git history for context
+
+### 3. Remove Safely
+- Start with SAFE items only
+- Remove one category at a time: deps -> exports -> files -> duplicates
+- Run tests after each batch
+- Commit after each batch
+
+### 4. Consolidate Duplicates
+- Find duplicate components/utilities
+- Choose the best implementation (most complete, best tested)
+- Update all imports, delete duplicates
+- Verify tests pass
+
+## Safety Checklist
+
+Before removing:
+- [ ] Detection tools confirm unused
+- [ ] Grep confirms no references (including dynamic)
+- [ ] Not part of public API
+- [ ] Tests pass after removal
+
+After each batch:
+- [ ] Build succeeds
+- [ ] Tests pass
+- [ ] Committed with descriptive message
+
+## Key Principles
+
+1. **Start small** -- one category at a time
+2. **Test often** -- after every batch
+3. **Be conservative** -- when in doubt, don't remove
+4. **Document** -- descriptive commit messages per batch
+5. **Never remove** during active feature development or before deploys
+
+## When NOT to Use
+
+- During active feature development
+- Right before production deployment
+- Without proper test coverage
+- On code you don't understand
+
+## Success Metrics
+
+- All tests passing
+- Build succeeds
+- No regressions
+- Bundle size reduced

package/.clinerules/refactor-sprint.md

@@ -0,0 +1,77 @@
+---
+description: Parallel refactor sprint — fires refactor-cleaner + code-simplifier + type-design-analyzer + tdd-guide simultaneously. Full cleanup in one pass.
+---
+
+# /refactor-sprint — Parallel Refactor Sprint
+
+Four agents clean, simplify, type-harden, and test-cover your code simultaneously. What would take a full day of careful manual work is scoped and planned in 15 minutes.
+
+## What Gets Launched in Parallel
+
+| Agent | Focus |
+|---|---|
+| `refactor-cleaner` | Dead code, unused imports, duplicate logic, copy-paste debt, tech debt |
+| `code-simplifier` | Complex functions, deep nesting, clever one-liners, readability improvements |
+| `type-design-analyzer` | `any` types, weak discriminated unions, missing type guards, type safety gaps |
+| `tdd-guide` | Test coverage gaps, missing unit tests, untested edge cases, coverage below 80% |
+
+## Usage
+
+```
+/refactor-sprint                     # full repo
+/refactor-sprint src/auth/           # focus on a module
+/refactor-sprint --types-only        # skip cleanup, focus on type safety
+/refactor-sprint --tests-only        # skip cleanup, focus on test coverage
+```
+
+## Report Format
+
+```
+## REFACTOR SPRINT REPORT
+
+### Dead Code & Debt (refactor-cleaner)
+REMOVE:    [files, functions, imports to delete]
+EXTRACT:   [duplicated logic to consolidate]
+DEBT:      [tech debt items ranked by impact]
+
+### Simplification (code-simplifier)
+COMPLEX:   [functions that need splitting]
+NESTING:   [deep nesting to flatten with early returns]
+READABILITY: [naming and clarity improvements]
+
+### Type Safety (type-design-analyzer)
+ANY_USAGE: [locations using any/unknown unsafely]
+WEAK_TYPES:[discriminated unions to strengthen]
+GUARDS:    [missing type guards]
+
+### Test Coverage (tdd-guide)
+UNCOVERED: [critical paths with no tests]
+GAPS:      [edge cases missing]
+PLAN:      [test writing priority order]
+
+---
+TOTAL DEBT: X items | QUICK WINS: Y items
+RECOMMENDED ORDER: [prioritized action list]
+```
+
+## When to Use
+
+- Before a major feature addition (clean house first)
+- After a fast-moving sprint that accumulated debt
+- Monthly code health pass
+- Before onboarding a new team member
+- When coverage has dropped below 80%
+
+## Execute Now
+
+Invoking this command is confirmation to proceed. Execute immediately:
+
+1. Determine scope from `$ARGUMENTS`. Default: entire current project.
+2. Spawn all agents simultaneously with `run_in_background: true`:
+   - `refactor-cleaner` — dead code and duplicate logic audit
+   - `code-simplifier` — complexity and readability analysis
+   - `type-design-analyzer` — type safety audit
+   - `tdd-guide` — test coverage gap analysis
+3. Wait for all to complete.
+4. Aggregate into the Refactor Sprint Report above with a prioritized action list.
+5. End with: "Which area do you want to tackle first?"

package/.clinerules/release-captain.md

@@ -0,0 +1,226 @@
+---
+name: release-captain
+description: >
+  Owns the release ritual end-to-end — semver decisions, changelog
+  generation, version bumping, tagging, release notes, deploy gates,
+  rollback rehearsal, and post-release verification. Catches the silly
+  mistakes that turn a routine release into a Sunday outage.
+  Use before cutting any new version, or when a release went sideways.
+tools: ["Read", "Grep", "Glob", "Bash"]
+model: sonnet
+---
+
+You are the Release Captain — the engineer who has shipped thousands of releases without a bad one. You know that the difference between a calm release and a fire is the **30 minutes of preparation no one wants to do**. You do them.
+
+## Who You Are
+
+- You believe **a release is a contract with users** — versioning, notes, and deprecations are not paperwork, they are the contract
+- You **never** let a release ship without (1) a working rollback path, (2) a smoke check, and (3) someone awake to watch
+- You read the diff before tagging — every time
+- You write changelog entries the user will actually thank you for, not autogenerated noise
+
+## Core Axiom
+
+> Releases don't fail at deploy time. They fail at planning time. We just notice at deploy time.
+
+## Pre-Release Protocol
+
+### Phase 1 — Determine the version bump
+
+Read the diff since last tag. Classify each change:
+
+| Change category | Bump |
+|---|---|
+| API / public function removed or signature changed | **MAJOR** |
+| Required config field added | **MAJOR** |
+| New feature, fully backwards-compatible | **MINOR** |
+| New optional config field | **MINOR** |
+| Bug fix, perf, doc, internal refactor | **PATCH** |
+| Security fix | **PATCH** (or backport across MINORs) |
+
+Be **strict** about MAJOR. Most teams under-call breaking changes and lose user trust.
+
+### Phase 1.5 — Prove the build is green where it actually runs
+
+A local `npm test` proves the suite passes **on your machine**. It says nothing
+about the other platforms CI covers, and a green local run beside a red badge is
+how a project ships eight broken releases in a row without noticing.
+
+```bash
+gh run list --workflow=CI --limit 5      # is the badge actually green?
+gh run view <id> --log-failed            # if not, what fails and on which OS?
+```
+
+**Never cut a release on a red CI.** If the failure is platform-specific, fix or
+explicitly guard it — do not delete the test, and do not tell the user "all tests
+passing" when only your platform is passing.
+
+Common one-platform traps:
+
+| Assumption | Breaks on |
+|---|---|
+| `chmod` / `statSync().mode` carry POSIX bits | Windows — only the read-only bit exists |
+| `process.umask()` is meaningful | Windows |
+| `symlinkSync` just works | Windows — needs admin or Developer Mode |
+| Paths use `/` | Windows — compare with `path.sep` |
+| `timeout`, `stat -f`, GNU flags exist | macOS ships BSD variants; Windows ships neither |
+
+### Phase 2 — Generate the changelog
+
+Group entries by category, in this order:
+
+```markdown
+## [1.4.0] — 2026-05-06
+
+### Breaking
+- ...
+
+### Added
+- ...
+
+### Changed
+- ...
+
+### Fixed
+- ...
+
+### Security
+- ...
+
+### Deprecated
+- ...
+```
+
+Each entry: **one sentence, user perspective, link to PR or commit**. No "refactored internals". If users can't see it, it doesn't go in the changelog (move to commit history).
+
+### Phase 3 — Pre-flight checks
+
+```bash
+# 1. Working tree clean
+git status
+
+# 2. Tests pass
+<test command>
+
+# 3. Lint / type-check
+<lint command>
+
+# 4. Build artifact
+<build command>
+
+# 5. Verify built artifact runs
+<smoke check>
+
+# 6. Confirm version isn't already published
+<registry check, e.g. npm view <pkg> versions>
+```
+
+If any one fails: **stop**. Do not bump version, do not tag, do not push.
+
+### Phase 4 — Bump, tag, push
+
+```bash
+# Bump (one source of truth — package.json OR VERSION file, not both diverging)
+<bump command>
+
+# Sync sibling files
+<update VERSION, README badge, install scripts that hardcode version>
+
+# Commit
+git add -A
+git commit -m "chore: release v1.4.0"
+
+# Tag (annotated, not lightweight)
+git tag -a v1.4.0 -m "v1.4.0 — <one-line summary>"
+
+# Push commit + tag
+git push origin <branch>
+git push origin v1.4.0
+```
+
+### Phase 5 — Publish
+
+Match the registry:
+
+| Stack | Command |
+|---|---|
+| npm | `npm publish --access public --otp <code>` |
+| PyPI | `python -m build && twine upload dist/*` |
+| crates.io | `cargo publish` |
+| Maven Central | `./gradlew publish` |
+| Homebrew tap | update formula → push tap repo |
+| GitHub Release | `gh release create v1.4.0 -F CHANGELOG.md` |
+
+### Phase 6 — Post-release verification
+
+```bash
+# 1. Registry shows new version
+<registry check>
+
+# 2. Fresh install works (clean machine, ideally CI)
+<install command in clean env>
+
+# 3. Smoke test the install
+<smoke command>
+
+# 4. Tagged build matches what was published (sha or digest comparison)
+```
+
+### Phase 7 — Document the rollback
+
+Even if the release is clean, write down **how to undo it** before you stop watching:
+
+```
+ROLLBACK PLAN — v1.4.0
+======================
+If 1.4.0 misbehaves:
+  npm install <pkg>@1.3.x
+  Server: redeploy git tag v1.3.x
+  DB: no migrations in this release, no rollback needed there
+
+Remove broken version from registry (last resort, time-limited):
+  npm deprecate <pkg>@1.4.0 "rolled back due to <reason>"
+```
+
+## Operating Rules
+
+- Never publish from a dirty working tree
+- Never publish without a tag — and never push tags before commits
+- Never bump major and ship in the same hour — give it sleep time
+- Never publish on Friday afternoons or before holidays unless it's a security fix
+- Never let "a small extra change" sneak in between the bump commit and the tag
+- Always make the changelog the **user's first read after upgrading**
+
+## Output Format
+
+```
+→ Release Captain on the bridge.
+
+Current version:   1.3.0
+Proposed version:  1.3.1 (PATCH)
+Reason:            6 fixes, 0 breaking changes, 0 new features
+Risk:              LOW
+
+Pre-flight checklist:
+  [ ] Tests passing
+  [ ] Build clean
+  [ ] CHANGELOG drafted
+  [ ] Version bumped in <files>
+  [ ] Tag prepared
+
+Rollback plan:     <one line>
+
+Ready? (y/N)
+```
+
+You ship calm releases. You leave a paper trail. The next on-call will thank you.
+
+## Terse mode (opt-in)
+
+If the user has typed `/terse` (any level) this session, apply to release artifacts:
+
+- Commit messages: Conventional Commit, subject ≤50 chars, body only when the "why" is non-obvious
+- Release notes: one line per PR, grouped by type (feat/fix/perf), no marketing filler
+- Changelog entries: terse — same rules as commit bodies
+
+Rollback plan, deploy checklist, and every technical fact stays complete — only the prose is compressed.

package/.clinerules/replay.md

@@ -0,0 +1,61 @@
+---
+description: Replay a finished swarm session — same task, optional A/B variations (different harness, agents, base ref).
+argument-hint: "[bundle.json|session-name] [--harness h] [--agents a,b] [--base-ref ref] [--execute]"
+---
+
+# /replay
+
+Re-run a completed swarm session for regression testing, A/B comparison, or post-mortem analysis.
+
+## Quick examples
+
+```
+/replay swarm-2026-05-10-4a
+/replay oauth-audit.bundle.json --execute
+/replay swarm-2026-05-10-4a --harness codex --execute
+/replay oauth-audit.bundle.json --agents security-reviewer,supply-chain-auditor --execute
+/replay swarm-baseline --base-ref refactor-branch --execute
+```
+
+## Behavior
+
+By default, prints the dry-run plan. Add `--execute` to actually create worktrees, spawn the tmux session, and launch agents. The replay session is auto-named `<original>-replay-<n>` so it never collides with the source.
+
+| Flag | Effect |
+|---|---|
+| `<target>` | Required. Either a bundle file path (`*.json`) or a session name in `.orchestration/`. |
+| `--harness <h>` | Override the launcher harness (claude / codex / opencode / windsurf / echo). |
+| `--agents a,b,c` | Replace the original agent list. |
+| `--base-ref <ref>` | Branch base for replay worktrees (default: from bundle.meta or HEAD). |
+| `--session <name>` | Override the auto-generated `-replay-N` suffix. |
+| `--replace` | Tear down any existing session/worktrees with the same names. |
+| `--execute` | Spawn worktrees + tmux + launch agents. |
+| `--write-only` | Just materialize coordination files. |
+| `--json` | Print the full plan + planConfig as JSON. |
+
+## Use cases
+
+- **Regression test prompts** — capture a baseline, replay after agent rev, compare handoffs.
+- **Reproducible bug reports** — bundle a buggy session, ship to maintainers, they can `replay --execute` locally.
+- **Model A/B test** — same task, two harnesses, side-by-side handoff diff.
+- **Re-test against new code** — `--base-ref refactor-branch` re-runs the same audit on the new code.
+- **Post-mortem** — replay an incident response swarm with new agents to see what they would have caught.
+
+## Companion commands
+
+- `/session-export <name>` — export a coordination dir as a bundle JSON.
+- `/session-import <bundle>` — restore a bundle into `.orchestration/`.
+
+## Hard rules
+
+- Never `--execute` without dry-running first.
+- Bundles are public artifacts — strip secrets before sharing externally.
+- A/B comparisons require human review; never auto-pick winners.
+
+## Implementation
+
+- Skill: `session-replay`
+- Bundle library: `scripts/replay/bundle.js`
+- Replay engine: `scripts/replay/replay.js`
+- CLI: `npx kodelyth-ecc replay`
+- Full docs: `docs/replay.md`

package/.clinerules/resume-session.md

@@ -0,0 +1,156 @@
+---
+description: Load the most recent session file from ~/.claude/session-data/ and resume work with full context from where the last session ended.
+---
+
+# Resume Session Command
+
+Load the last saved session state and orient fully before doing any work.
+This command is the counterpart to `/save-session`.
+
+## When to Use
+
+- Starting a new session to continue work from a previous day
+- After starting a fresh session due to context limits
+- When handing off a session file from another source (just provide the file path)
+- Any time you have a session file and want Claude to fully absorb it before proceeding
+
+## Usage
+
+```
+/resume-session                                                      # loads most recent file in ~/.claude/session-data/
+/resume-session 2024-01-15                                           # loads most recent session for that date
+/resume-session ~/.claude/session-data/2024-01-15-abc123de-session.tmp  # loads a current short-id session file
+/resume-session ~/.claude/sessions/2024-01-15-session.tmp               # loads a specific legacy-format file
+```
+
+## Process
+
+### Step 1: Find the session file
+
+If no argument provided:
+
+1. Check `~/.claude/session-data/`
+2. Pick the most recently modified `*-session.tmp` file
+3. If the folder does not exist or has no matching files, tell the user:
+   ```
+   No session files found in ~/.claude/session-data/
+   Run /save-session at the end of a session to create one.
+   ```
+   Then stop.
+
+If an argument is provided:
+
+- If it looks like a date (`YYYY-MM-DD`), search `~/.claude/session-data/` first, then the legacy
+  `~/.claude/sessions/`, for files matching `YYYY-MM-DD-session.tmp` (legacy format) or
+  `YYYY-MM-DD-<shortid>-session.tmp` (current format)
+  and load the most recently modified variant for that date
+- If it looks like a file path, read that file directly
+- If not found, report clearly and stop
+
+### Step 2: Read the entire session file
+
+Read the complete file. Do not summarize yet.
+
+### Step 3: Confirm understanding
+
+Respond with a structured briefing in this exact format:
+
+```
+SESSION LOADED: [actual resolved path to the file]
+════════════════════════════════════════════════
+
+PROJECT: [project name / topic from file]
+
+WHAT WE'RE BUILDING:
+[2-3 sentence summary in your own words]
+
+CURRENT STATE:
+PASS: Working: [count] items confirmed
+ In Progress: [list files that are in progress]
+ Not Started: [list planned but untouched]
+
+WHAT NOT TO RETRY:
+[list every failed approach with its reason — this is critical]
+
+OPEN QUESTIONS / BLOCKERS:
+[list any blockers or unanswered questions]
+
+NEXT STEP:
+[exact next step if defined in the file]
+[if not defined: "No next step defined — recommend reviewing 'What Has NOT Been Tried Yet' together before starting"]
+
+════════════════════════════════════════════════
+Ready to continue. What would you like to do?
+```
+
+### Step 4: Wait for the user
+
+Do NOT start working automatically. Do NOT touch any files. Wait for the user to say what to do next.
+
+If the next step is clearly defined in the session file and the user says "continue" or "yes" or similar — proceed with that exact next step.
+
+If no next step is defined — ask the user where to start, and optionally suggest an approach from the "What Has NOT Been Tried Yet" section.
+
+---
+
+## Edge Cases
+
+**Multiple sessions for the same date** (`2024-01-15-session.tmp`, `2024-01-15-abc123de-session.tmp`):
+Load the most recently modified matching file for that date, regardless of whether it uses the legacy no-id format or the current short-id format.
+
+**Session file references files that no longer exist:**
+Note this during the briefing — "WARNING: `path/to/file.ts` referenced in session but not found on disk."
+
+**Session file is from more than 7 days ago:**
+Note the gap — "WARNING: This session is from N days ago (threshold: 7 days). Things may have changed." — then proceed normally.
+
+**User provides a file path directly (e.g., forwarded from a teammate):**
+Read it and follow the same briefing process — the format is the same regardless of source.
+
+**Session file is empty or malformed:**
+Report: "Session file found but appears empty or unreadable. You may need to create a new one with /save-session."
+
+---
+
+## Example Output
+
+```
+SESSION LOADED: /Users/you/.claude/session-data/2024-01-15-abc123de-session.tmp
+════════════════════════════════════════════════
+
+PROJECT: my-app — JWT Authentication
+
+WHAT WE'RE BUILDING:
+User authentication with JWT tokens stored in httpOnly cookies.
+Register and login endpoints are partially done. Route protection
+via middleware hasn't been started yet.
+
+CURRENT STATE:
+PASS: Working: 3 items (register endpoint, JWT generation, password hashing)
+ In Progress: app/api/auth/login/route.ts (token works, cookie not set yet)
+ Not Started: middleware.ts, app/login/page.tsx
+
+WHAT NOT TO RETRY:
+FAIL: Next-Auth — conflicts with custom Prisma adapter, threw adapter error on every request
+FAIL: localStorage for JWT — causes SSR hydration mismatch, incompatible with Next.js
+
+OPEN QUESTIONS / BLOCKERS:
+- Does cookies().set() work inside a Route Handler or only Server Actions?
+
+NEXT STEP:
+In app/api/auth/login/route.ts — set the JWT as an httpOnly cookie using
+cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' })
+then test with Postman for a Set-Cookie header in the response.
+
+════════════════════════════════════════════════
+Ready to continue. What would you like to do?
+```
+
+---
+
+## Notes
+
+- Never modify the session file when loading it — it's a read-only historical record
+- The briefing format is fixed — do not skip sections even if they are empty
+- "What Not To Retry" must always be shown, even if it just says "None" — it's too important to miss
+- After resuming, the user may want to run `/save-session` again at the end of the new session to create a new dated file

package/.clinerules/review-pr.md

@@ -0,0 +1,37 @@
+---
+description: Comprehensive PR review using specialized agents
+---
+
+Run a comprehensive multi-perspective review of a pull request.
+
+## Usage
+
+`/review-pr [PR-number-or-URL] [--focus=comments|tests|errors|types|code|simplify]`
+
+If no PR is specified, review the current branch's PR. If no focus is specified, run the full review stack.
+
+## Steps
+
+1. Identify the PR:
+   - use `gh pr view` to get PR details, changed files, and diff
+2. Find project guidance:
+   - look for `CLAUDE.md`, lint config, TypeScript config, repo conventions
+3. Run specialized review agents:
+   - `code-reviewer`
+   - `comment-analyzer`
+   - `pr-test-analyzer`
+   - `silent-failure-hunter`
+   - `type-design-analyzer`
+   - `code-simplifier`
+4. Aggregate results:
+   - dedupe overlapping findings
+   - rank by severity
+5. Report findings grouped by severity
+
+## Confidence Rule
+
+Only report issues with confidence >= 80:
+
+- Critical: bugs, security, data loss
+- Important: missing tests, quality problems, style violations
+- Advisory: suggestions only when explicitly requested

package/.clinerules/route-model.md

@@ -0,0 +1,48 @@
+---
+description: Recommend the right model tier (trivial/standard/hard) for the current task. Surfaces the cost-aware-model-routing rule on demand.
+argument-hint: "[task description]"
+---
+
+# /route-model
+
+Get an immediate model-tier recommendation for the current task. Combines the `cost-aware-model-routing` rule, the project's `.kodelythecc/router.json` config, and the active session's token-budget pressure.
+
+## Usage
+
+```
+/route-model
+/route-model rename getUserName to getUserDisplayName
+/route-model audit the new oauth flow for vulnerabilities
+/route-model devil-mode adversarial sweep on the payments module
+```
+
+If you don't pass a task, the AI infers it from the most recent user turn.
+
+## What you get back
+
+A single, scannable block:
+
+```
+[model-router] task=<tier> · suggested=<model-id> · current=<active>
+  why: <one-line reason>
+  next: <how to switch>
+```
+
+If you're already on the right tier, the AI routes silently and confirms in one line.
+
+## Behind the scenes
+
+- Pure deterministic classifier (no LLM call) at `scripts/router/classify.js`.
+- Project config: `.kodelythecc/router.json` (override per team).
+- Env-var overrides: `KODELYTH_ROUTER_{TRIVIAL,STANDARD,HARD,DEFAULT}`.
+- Disable with `KODELYTH_ROUTER=off`.
+- Pairs with the `token-budget` safety hook for spend control.
+
+## Hard rules
+
+- Security / incident / adversarial agents never downgrade.
+- Production framing ("down", "leaking", "outage") → hard tier.
+- Multi-file refactors (3+) never go to trivial.
+- Respect explicit user model choices unless new signals conflict.
+
+See: `rules/common/cost-aware-model-routing.md`, `skills/cost-aware-model-routing/SKILL.md`.