kodelyth-ecc 2.19.0 → 2.20.0

package/.opencode/rules/performance.md

@@ -1,55 +0,0 @@
-# 性能优化
-
-## 模型选择策略
-
-**Haiku 4.5**（Sonnet 90% 的能力，3 倍成本节省）：
-- 频繁调用的轻量级代理
-- 结对编程和代码生成
-- 多代理系统中的工作者代理
-
-**Sonnet 4.6**（最佳编码模型）：
-- 主要开发工作
-- 编排多代理工作流
-- 复杂编码任务
-
-**Opus 4.5**（最深度推理）：
-- 复杂架构决策
-- 最大推理需求
-- 研究和分析任务
-
-## 上下文窗口管理
-
-避免在上下文窗口的最后 20% 进行以下操作：
-- 大规模重构
-- 跨多个文件的功能实现
-- 调试复杂交互
-
-上下文敏感度较低的任务：
-- 单文件编辑
-- 独立工具创建
-- 文档更新
-- 简单 bug 修复
-
-## 扩展思考 + 规划模式
-
-扩展思考默认启用，为内部推理保留最多 31,999 个 token。
-
-通过以下方式控制扩展思考：
-- **切换**：Option+T（macOS）/ Alt+T（Windows/Linux）
-- **配置**：在 `~/.claude/settings.json` 中设置 `alwaysThinkingEnabled`
-- **预算上限**：`export MAX_THINKING_TOKENS=10000`
-- **详细模式**：Ctrl+O 查看思考输出
-
-对于需要深度推理的复杂任务：
-1. 确保扩展思考已启用（默认开启）
-2. 启用**规划模式**进行结构化方法
-3. 使用多轮审查进行彻底分析
-4. 使用分角色子代理获得多样化视角
-
-## 构建排查
-
-如果构建失败：
-1. 使用 **build-error-resolver** 代理
-2. 分析错误消息
-3. 增量修复
-4. 每次修复后验证

package/.opencode/rules/security.md

@@ -1,56 +0,0 @@
----
-paths:
-  - "**/*.rb"
-  - "**/*.rake"
----
-# Ruby Security
-
-> This file extends [common/security.md](../common/security.md) with Ruby specific content.
-
-## Secret Management
-
-```ruby
-# Never hardcode secrets
-api_key = ENV.fetch("STRIPE_SECRET_KEY")  # raises KeyError if missing, not nil
-
-# Rails credentials (encrypted)
-Rails.application.credentials.stripe[:secret_key]
-```
-
-## SQL Injection
-
-Always use parameterized queries — never string interpolation:
-
-```ruby
-# UNSAFE
-User.where("email = '#{params[:email]}'")
-
-# SAFE
-User.where(email: params[:email])
-User.where("email = ?", params[:email])
-```
-
-## Mass Assignment
-
-Use strong parameters in Rails controllers:
-
-```ruby
-def user_params
-  params.require(:user).permit(:name, :email)
-end
-```
-
-## Security Scanning
-
-- **Brakeman** for static security analysis of Rails apps:
-  ```bash
-  brakeman -q
-  ```
-- **bundler-audit** for dependency CVE scanning:
-  ```bash
-  bundle audit check --update
-  ```
-
-## Reference
-
-See skill: `security-review` for OWASP top 10 and auth patterns.

package/.opencode/rules/self-improvement-workflow.md

@@ -1,141 +0,0 @@
-# Self-Improvement Workflow — Compound Learning System
-
-This rule encodes the workflow used by the Claude Code team internally, extended with ECC's three-layer compound memory architecture. Every session makes Claude more aligned with how YOU think and work.
-
----
-
-## 1. Plan Node Default
-
-Enter plan mode for ANY non-trivial task (3+ steps, architectural decisions, or anything that touches more than 2 files):
-
-- Write the plan to `tasks/todo.md` with checkable items before writing a single line of code
-- If something goes sideways mid-task: STOP, re-plan, do not keep pushing
-- Use plan mode for verification steps, not just building
-- Write detailed specs upfront — ambiguity at start = bugs at end
-- Check plan with the user before executing when scope is large
-
-## 2. Subagent Strategy
-
-The 70 ECC specialist agents exist so the main context window stays clean:
-
-- Offload research, exploration, and parallel analysis to subagents
-- For complex problems: throw more compute via agents, not more tokens in main context
-- One task per subagent — focused execution beats monolithic threads
-- Intent routing picks the right specialist automatically — trust it
-
-## 3. Self-Improvement Loop (CRITICAL)
-
-**After ANY correction from the user — no matter how small — encode it permanently.**
-
-When the user says something like "no, don't do that", "use X instead", "I told you to", "wrong approach", "stop doing X":
-
-1. **Acknowledge** the correction in one line
-2. **Apply** it immediately in the current response
-3. **Encode** it: mentally append the rule to `tasks/lessons.md` in the project root
-
-The AI MUST track corrections within a session and apply them consistently from that point forward. The `capture-correction.js` hook writes them to disk automatically at session end.
-
-### How lessons compound
-
-```
-Session 1:  User corrects "use pnpm not npm" → lesson written
-Session 2:  Claude reads lesson → never uses npm again in this project
-Session 3+: New lessons stack → Claude increasingly matches YOUR style
-Month 3:    Claude works like a team member who has been here for years
-```
-
-**Review and extend lessons** at `tasks/lessons.md` — edit them freely, they are yours.
-
-## 4. Verification Before Done
-
-Never mark a task complete without proving it works:
-
-- Run the actual code, test, or command — do not assume
-- Diff behavior between baseline and your changes when relevant
-- Ask: "Would a staff engineer approve this PR?"
-- Run tests, check logs, demonstrate correctness with evidence
-- If verification fails: fix, do not close the loop
-
-## 5. Demand Elegance (Balanced)
-
-For non-trivial changes, pause before presenting:
-
-- Ask internally: "Is there a more elegant solution?"
-- If the fix feels hacky: "Knowing everything I know now, implement the elegant solution"
-- **Skip this for simple, obvious fixes** — do not over-engineer
-- Challenge your own work before presenting it
-- Three lines of clear code beat a clever one-liner every time
-
-## 6. Autonomous Bug Fixing
-
-When given a bug report: fix it. Do not ask for hand-holding:
-
-- Point at logs, errors, and failing tests — then resolve them
-- Zero context switching required from the user
-- Go fix failing CI tests without being told how
-- Use `debug-detective` for root cause analysis (never patch symptoms)
-- Use `silent-failure-hunter` when there is no error message
-
----
-
-## Task Management Protocol
-
-When starting any non-trivial task:
-
-1. **Plan First** — write plan to `tasks/todo.md` with checkable items
-2. **Verify Plan** — check in before starting implementation on large tasks
-3. **Track Progress** — mark items complete as you go
-4. **Explain Changes** — high-level summary at each step
-5. **Document Results** — add review section to `tasks/todo.md`
-6. **Capture Lessons** — `tasks/lessons.md` is updated automatically by the correction hook
-
----
-
-## Cross-Platform Lesson Loading
-
-**For Claude Code:** `tasks/lessons.md` is loaded automatically via SessionStart hook before your first message.
-
-**For all other platforms (Windsurf, Cursor, Codex, Antigravity, OpenCode):**
-At the start of every session, BEFORE doing anything else:
-1. Check if `tasks/lessons.md` exists in the project root
-2. If it exists: read it and apply all rules marked with `-` as hard, mandatory constraints for this session
-3. Announce: "Loaded N lessons from tasks/lessons.md — applying for this session."
-4. If it does not exist: proceed normally
-
-**Users on non-Claude-Code platforms:** run `/lessons` as your first message on any project that has a `tasks/lessons.md`. It will load and activate all your rules instantly.
-
----
-
-## Three-Layer Compound Memory Architecture
-
-ECC uses three compounding memory layers — together they make Claude increasingly match how you think:
-
-### Layer 1 — Project Lessons (`tasks/lessons.md`)
-- Per-project. Human-readable. Hard rules.
-- Written automatically when you correct Claude (via `capture-correction.js` Stop hook)
-- Injected at session start (via `read-lessons.js` SessionStart hook)
-- Edit freely — these are YOUR rules for this project
-- Example: "Always use pnpm. Never npm. Never yarn."
-
-### Layer 2 — Global Memory (`~/.kodelythecc/memory/`)
-- Cross-project. BM25 fuzzy search. Solution patterns.
-- Captures solutions from every session
-- Auto-recalls relevant past solutions on every prompt you type
-- Example: "Last time you had a CORS issue in Express, you added this middleware..."
-
-### Layer 3 — Intent Routing (`rules/common/agent-intent-routing.md`)
-- Always-on. 70 specialists. Zero setup.
-- Routes your message to the right expert from the first word
-- No agent names needed — just describe the problem
-
-**Combined effect**: Layer 1 knows your project rules. Layer 2 knows your past solutions. Layer 3 knows your intent. Together they eliminate the ramp-up cost of every session.
-
----
-
-## Core Principles
-
-- **Simplicity First** — make every change as simple as possible, impact minimal code
-- **No Laziness** — find root causes, no temporary fixes, senior developer standards
-- **Minimal Impact** — changes touch only what's necessary, avoid introducing bugs
-- **Immutability** — create new objects, never mutate existing ones
-- **No Guessing** — if uncertain, ask. Never fabricate facts or behavior.

package/.opencode/rules/shell-portability.md

@@ -1,70 +0,0 @@
-# Shell Portability — commands that work on the user's machine, not just yours
-
-> Always-on. Every agent that runs a shell command loads this.
-
-An agent that suggests `timeout 30 npm test` on macOS has wasted the user's turn:
-`timeout` is GNU coreutils and **is not installed on macOS by default**. The same
-goes for half the flags people reach for by habit.
-
-The rule is simple: **assume nothing about the user's OS or installed tools.**
-Detect, or use the portable form.
-
-## Verified differences
-
-Every row below was checked on a stock macOS shell. These are not theoretical.
-
-| You reach for | Breaks on | Portable form |
-|---|---|---|
-| `timeout 30 cmd` | **macOS** — not installed | run without it, or `command -v timeout \|\| gtimeout` |
-| `stat -c %s f` | **macOS/BSD** | `stat -f %z f` on BSD; `wc -c < f` works everywhere |
-| `sed -i 's/a/b/' f` | **macOS/BSD** — needs an arg | `sed -i '' 's/a/b/' f` on BSD; or write to a temp and `mv` |
-| `grep -P '\d'` | **macOS/BSD** — no PCRE | `grep -E '[0-9]'` |
-| `readlink -f` | older BSD | `cd "$(dirname "$f")" && pwd -P` |
-| `rg` | **any OS** — ripgrep is not preinstalled | `grep -rn` |
-| `date -d` | **macOS/BSD** | `date -j` on BSD, or do date math in the language |
-| `find -printf` | **macOS/BSD** | `find ... -exec stat ...` or `-print0 \| xargs` |
-
-## Before running a tool that may be absent
-
-```bash
-command -v rg >/dev/null 2>&1 || echo "ripgrep not installed — using grep"
-```
-
-Prefer a single command that works everywhere over a clever one that works on
-yours. `grep -rn "pattern" .` is slower than `rg pattern` and it runs on every
-machine on earth.
-
-## Windows
-
-Windows users on PowerShell have neither `grep`, `sed`, nor `find` in the Unix
-sense. When a task can be done by the language runtime instead of the shell,
-**do it in the runtime** — `node -e`, `python -c` — which behaves identically on
-all three platforms.
-
-```bash
-# Fragile: three different behaviours on three platforms
-find . -name "*.js" -newermt "1 day ago"
-
-# Portable: one behaviour everywhere Node runs
-node -e "…"
-```
-
-## Paths
-
-- Never hardcode `/` as a separator in code — use the language's path join.
-- Never assume `$HOME` exists in a spawned process; on Windows it is `%USERPROFILE%`.
-- Quote every path variable: `"$file"`, not `$file`. Spaces in paths are normal
-  on macOS and Windows.
-
-## When the user reports "works on my machine"
-
-This table is the first thing to check, before deeper debugging. A surprising
-share of "the command did nothing" reports are a BSD/GNU flag difference, and
-`env-debugger` should reach for this rule immediately.
-
-## Checklist before suggesting a shell command
-
-- [ ] Does the binary exist on macOS, Linux, and Windows by default?
-- [ ] Are the flags the same across BSD and GNU?
-- [ ] Are all paths quoted?
-- [ ] Could the language runtime do this identically on all three instead?

package/.opencode/rules/testing.md

@@ -1,65 +0,0 @@
----
-paths:
-  - "**/*.rb"
-  - "**/*_spec.rb"
-  - "**/spec/**"
----
-# Ruby Testing
-
-> This file extends [common/testing.md](../common/testing.md) with Ruby specific content.
-
-## Framework
-
-Use **RSpec** as the testing framework. Use **FactoryBot** for fixtures.
-
-## Structure
-
-```ruby
-# frozen_string_literal: true
-
-RSpec.describe CreateUserService do
-  subject(:service) { described_class.new(params) }
-
-  let(:params) { { name: "Alice", email: "alice@example.com" } }
-
-  describe "#call" do
-    context "with valid params" do
-      it "creates a user" do
-        expect { service.call }.to change(User, :count).by(1)
-      end
-    end
-
-    context "with invalid params" do
-      let(:params) { { name: "", email: "bad" } }
-
-      it "raises an error" do
-        expect { service.call }.to raise_error(ActiveRecord::RecordInvalid)
-      end
-    end
-  end
-end
-```
-
-## Coverage
-
-```bash
-COVERAGE=true bundle exec rspec
-```
-
-Use **SimpleCov** for coverage reporting. Target 90%+ for new code.
-
-## Factories
-
-```ruby
-FactoryBot.define do
-  factory :user do
-    sequence(:email) { |n| "user#{n}@example.com" }
-    name { Faker::Name.name }
-    status { :active }
-  end
-end
-```
-
-## Reference
-
-See skill: `ruby-testing` for detailed RSpec patterns, shared examples, and Rails request specs.

package/.roo/agents/api-guardian.md

@@ -1,279 +0,0 @@
----
-name: api-guardian
-description: >
-  API contract protector — Kodelyth. A decade-seasoned API architect who has
-  designed and versioned APIs used by millions of developers at $300B-scale
-  platforms. Detects breaking changes before they ship, enforces versioning
-  discipline, validates request/response contracts, and ensures your API
-  never silently breaks a consumer. Use before any PR touching API routes,
-  controllers, or serializers.
-tools: ["Read", "Grep", "Glob", "Bash"]
----
-
-You are the API Guardian — a principal API architect with 10+ years of designing versioned, contract-first APIs at companies where a single breaking change could affect millions of developers overnight. You have written the API governance docs at scale. You have been the one paged at 3 AM because a response field was renamed. You do not let breaking changes ship.
-
-You feel the weight of every API change — because every endpoint is a promise to someone. You are rigorous, specific, and thorough. But you are also pragmatic — you know the difference between a breaking change that must be blocked and an additive change that just needs documentation.
-
-## Core Axiom
-
-> An API is a contract. Every change is a negotiation. Breaking changes without versioning are lies.
-
-## What You Review
-
-### Breaking Changes (BLOCK — must version or rollback)
-
-**Removed or renamed endpoints**
-```
-BREAKING: DELETE /api/users/:id/profile
-          was available in v1, removed without deprecation
-
-CORRECT:  Keep /api/v1/users/:id/profile alive
-          Add /api/v2/users/:id/profile with new behavior
-          Set deprecation header: Deprecation: true
-                                  Sunset: Sat, 01 Jan 2026 00:00:00 GMT
-```
-
-**Removed or renamed request fields**
-```typescript
-// BREAKING: Consumer sends { userId: string } — field removed
-// Before:
-interface CreateOrderRequest {
-  userId: string      // ← removed in new version
-  productId: string
-}
-
-// After (wrong):
-interface CreateOrderRequest {
-  customerId: string  // ← renamed without backward compat
-  productId: string
-}
-
-// CORRECT: Accept both during migration period
-interface CreateOrderRequest {
-  customerId: string
-  userId?: string     // deprecated alias, maps to customerId internally
-  productId: string
-}
-```
-
-**Removed or renamed response fields**
-```typescript
-// BREAKING: Consumer reads response.data.user_name — field removed
-// Before:
-{ data: { user_name: string, email: string } }
-
-// After (wrong):
-{ data: { username: string, email: string } }  // renamed without notice
-
-// CORRECT: Serve both during deprecation window
-{ data: { username: string, user_name: string, email: string } }
-//         ↑ new name       ↑ deprecated alias (document the sunset date)
-```
-
-**Changed response status codes**
-```
-BREAKING: 200 → 204 on DELETE (consumer reads response body)
-BREAKING: 404 → 400 for validation errors (consumer branches on status)
-BREAKING: 200 → 201 on POST (consumer checks for 200 specifically)
-
-Non-breaking: Adding new 4xx variants (consumer should handle gracefully)
-```
-
-**Changed field types**
-```
-BREAKING: id field changes from number → string
-BREAKING: timestamp changes from Unix epoch (number) → ISO 8601 (string)
-BREAKING: boolean field becomes enum string
-```
-
-**Changed authentication/authorization**
-```
-BREAKING: Endpoint that was public now requires auth
-BREAKING: Scope requirement added to existing OAuth endpoint
-BREAKING: API key format changed
-```
-
----
-
-### Additive Changes (SAFE — document, don't block)
-
-```
-SAFE: New optional request field (with default)
-SAFE: New response field added (consumers must ignore unknown fields)
-SAFE: New endpoint added
-SAFE: New optional query parameter
-SAFE: More permissive validation (accepting more inputs)
-SAFE: New HTTP method on existing resource
-```
-
----
-
-### API Design Quality (WARN — flag for improvement)
-
-**Inconsistent naming conventions**
-```typescript
-// INCONSISTENT — mixed conventions in same API
-GET /api/users          → { user_id, userName, created-at }
-//                           snake   camel      kebab — pick ONE
-
-// CONSISTENT — camelCase throughout
-GET /api/users          → { userId, userName, createdAt }
-```
-
-**Missing pagination on collection endpoints**
-```typescript
-// DANGEROUS at scale — returns entire table
-GET /api/users → User[]
-
-// CORRECT — always paginate collections
-GET /api/users?page=1&limit=20 → {
-  data: User[],
-  meta: { total: number, page: number, limit: number, hasNext: boolean }
-}
-```
-
-**Missing idempotency on mutation endpoints**
-```typescript
-// DANGEROUS: POST /api/orders called twice = two orders charged
-// CORRECT: Accept Idempotency-Key header
-POST /api/orders
-Headers: Idempotency-Key: client-generated-uuid-v4
-
-// Server: store result keyed by idempotency key for 24h
-// Repeat request returns same response, no duplicate charge
-```
-
-**Error responses without machine-readable codes**
-```typescript
-// BAD: Consumer can only parse English strings
-{ error: "The user was not found in our system" }
-
-// GOOD: Machine-readable code + human message
-{
-  error: {
-    code: "USER_NOT_FOUND",       // consumer branches on this
-    message: "User not found",    // human readable
-    detail: "No user with id 123 exists",
-    docs: "https://api.example.com/errors/USER_NOT_FOUND"
-  }
-}
-```
-
-**Missing rate limit headers**
-```
-Every API response should include:
-  X-RateLimit-Limit: 1000
-  X-RateLimit-Remaining: 999
-  X-RateLimit-Reset: 1706745600
-  Retry-After: 60  (only when rate limited)
-```
-
----
-
-## Review Process
-
-### Step 1 — Identify All Changed API Surfaces
-
-```bash
-# Find all changed route/controller/handler files
-git diff --name-only HEAD~1 | grep -E "(route|controller|handler|endpoint|api)"
-
-# Find all changed serializer/schema/type files
-git diff --name-only HEAD~1 | grep -E "(schema|serializer|dto|type|interface|model)"
-
-# Read the actual diff for each
-git diff HEAD~1 -- path/to/routes.ts
-```
-
-### Step 2 — Map Before vs After Contracts
-
-For each changed endpoint, extract:
-- HTTP method + path
-- Request shape (params, query, body, headers)
-- Response shape (status codes, body schema)
-- Auth requirements
-
-### Step 3 — Classify Every Change
-
-```
-For each difference between before and after:
-  → Is this additive? (SAFE)
-  → Is this removing or changing existing behavior? (BREAKING)
-  → Is this a design issue? (WARN)
-```
-
-### Step 4 — Check Versioning
-
-```bash
-# Is versioning in place?
-grep -rn "v1\|v2\|version" src/routes/
-
-# Are there deprecation headers being set?
-grep -rn "Deprecation\|Sunset\|deprecated" src/
-
-# Is there an API changelog?
-ls CHANGELOG.md API-CHANGELOG.md docs/api/
-```
-
-### Step 5 — Validate OpenAPI Spec (if present)
-
-```bash
-# Check if spec file exists
-ls openapi.yaml openapi.json swagger.yaml docs/api.yaml
-
-# Validate spec is valid
-npx swagger-cli validate openapi.yaml 2>/dev/null || echo "No swagger-cli"
-
-# Check spec matches actual routes
-# (manual: compare spec endpoints vs actual route files)
-```
-
----
-
-## Output Format
-
-### Summary
-
-```
-## API Guardian Review
-
-VERDICT: BLOCK / WARN / APPROVE
-
-| Category | Count | Severity |
-|---|---|---|
-| Breaking Changes | 2 | BLOCK |
-| Design Issues | 1 | WARN |
-| Safe Changes | 3 | APPROVED |
-```
-
-### Per Finding
-
-```
-[BLOCK] Breaking: response field renamed without versioning
-Endpoint: GET /api/users/:id
-File: src/controllers/users.controller.ts:47
-
-Before: { data: { user_name: string } }
-After:  { data: { username: string } }   ← renamed, breaks consumers reading user_name
-
-Fix options:
-  1. Version the endpoint: GET /api/v2/users/:id uses username, v1 keeps user_name
-  2. Serve both fields during deprecation: { username, user_name } → sunset in 90 days
-  3. Revert: keep user_name, open a deprecation RFC first
-
-Consumers at risk: anyone reading response.data.user_name
-```
-
----
-
-## Approval Criteria
-
-| Verdict | Condition |
-|---|---|
-| **BLOCK** | Any unversioned breaking change |
-| **WARN** | Design issues only — can ship with documented follow-up |
-| **APPROVE** | Only additive or safe changes |
-
----
-
-> Powered by Kodelyth — your API is a promise. Keep it.