kodelyth-ecc 2.19.0 → 2.21.0

package/.kimi/skills/defi-amm-security/SKILL.md

@@ -1,160 +0,0 @@
----
-name: defi-amm-security
-description: Security checklist for Solidity AMM contracts, liquidity pools, and swap flows. Covers reentrancy, CEI ordering, donation or inflation attacks, oracle manipulation, slippage, admin controls, and integer math.
-origin: ECC direct-port adaptation
-version: "1.0.0"
----
-
-# DeFi AMM Security
-
-Critical vulnerability patterns and hardened implementations for Solidity AMM contracts, LP vaults, and swap functions.
-
-## When to Use
-
-- Writing or auditing a Solidity AMM or liquidity-pool contract
-- Implementing swap, deposit, withdraw, mint, or burn flows that hold token balances
-- Reviewing any contract that uses `token.balanceOf(address(this))` in share or reserve math
-- Adding fee setters, pausers, oracle updates, or other admin functions to a DeFi protocol
-
-## How It Works
-
-Use this as a checklist-plus-pattern library. Review every user entrypoint against the categories below and prefer the hardened examples over hand-rolled variants.
-
-## Examples
-
-### Reentrancy: enforce CEI order
-
-Vulnerable:
-
-```solidity
-function withdraw(uint256 amount) external {
-    require(balances[msg.sender] >= amount);
-    token.transfer(msg.sender, amount);
-    balances[msg.sender] -= amount;
-}
-```
-
-Safe:
-
-```solidity
-import {ReentrancyGuard} from "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
-import {SafeERC20} from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
-
-using SafeERC20 for IERC20;
-
-function withdraw(uint256 amount) external nonReentrant {
-    require(balances[msg.sender] >= amount, "Insufficient");
-    balances[msg.sender] -= amount;
-    token.safeTransfer(msg.sender, amount);
-}
-```
-
-Do not write your own guard when a hardened library exists.
-
-### Donation or inflation attacks
-
-Using `token.balanceOf(address(this))` directly for share math lets attackers manipulate the denominator by sending tokens to the contract outside the intended path.
-
-```solidity
-// Vulnerable
-function deposit(uint256 assets) external returns (uint256 shares) {
-    shares = (assets * totalShares) / token.balanceOf(address(this));
-}
-```
-
-```solidity
-// Safe
-uint256 private _totalAssets;
-
-function deposit(uint256 assets) external nonReentrant returns (uint256 shares) {
-    uint256 balBefore = token.balanceOf(address(this));
-    token.safeTransferFrom(msg.sender, address(this), assets);
-    uint256 received = token.balanceOf(address(this)) - balBefore;
-
-    shares = totalShares == 0 ? received : (received * totalShares) / _totalAssets;
-    _totalAssets += received;
-    totalShares += shares;
-}
-```
-
-Track internal accounting and measure actual tokens received.
-
-### Oracle manipulation
-
-Spot prices are flash-loan manipulable. Prefer TWAP.
-
-```solidity
-uint32[] memory secondsAgos = new uint32[](2);
-secondsAgos[0] = 1800;
-secondsAgos[1] = 0;
-(int56[] memory tickCumulatives,) = IUniswapV3Pool(pool).observe(secondsAgos);
-int24 twapTick = int24(
-    (tickCumulatives[1] - tickCumulatives[0]) / int56(uint56(30 minutes))
-);
-uint160 sqrtPriceX96 = TickMath.getSqrtRatioAtTick(twapTick);
-```
-
-### Slippage protection
-
-Every swap path needs caller-provided slippage and a deadline.
-
-```solidity
-function swap(
-    uint256 amountIn,
-    uint256 amountOutMin,
-    uint256 deadline
-) external returns (uint256 amountOut) {
-    require(block.timestamp <= deadline, "Expired");
-    amountOut = _calculateOut(amountIn);
-    require(amountOut >= amountOutMin, "Slippage exceeded");
-    _executeSwap(amountIn, amountOut);
-}
-```
-
-### Safe reserve math
-
-```solidity
-import {FullMath} from "@uniswap/v3-core/contracts/libraries/FullMath.sol";
-
-uint256 result = FullMath.mulDiv(a, b, c);
-```
-
-For large reserve math, avoid naive `a * b / c` when overflow risk exists.
-
-### Admin controls
-
-```solidity
-import {Ownable2Step} from "@openzeppelin/contracts/access/Ownable2Step.sol";
-
-contract MyAMM is Ownable2Step {
-    function setFee(uint256 fee) external onlyOwner { ... }
-    function pause() external onlyOwner { ... }
-}
-```
-
-Prefer explicit acceptance for ownership transfer and gate every privileged path.
-
-## Security Checklist
-
-- Reentrancy-exposed entrypoints use `nonReentrant`
-- CEI ordering is respected
-- Share math does not depend on raw `balanceOf(address(this))`
-- ERC-20 transfers use `SafeERC20`
-- Deposits measure actual tokens received
-- Oracle reads use TWAP or another manipulation-resistant source
-- Swaps require `amountOutMin` and `deadline`
-- Overflow-sensitive reserve math uses safe primitives like `mulDiv`
-- Admin functions are access-controlled
-- Emergency pause exists and is tested
-- Static analysis and fuzzing are run before production
-
-## Audit Tools
-
-```bash
-pip install slither-analyzer
-slither . --exclude-dependencies
-
-echidna-test . --contract YourAMM --config echidna.yaml
-
-forge test --fuzz-runs 10000
-```

package/.kimi/skills/deployment-patterns/SKILL.md

@@ -1,427 +0,0 @@
----
-name: deployment-patterns
-description: Deployment workflows, CI/CD pipeline patterns, Docker containerization, health checks, rollback strategies, and production readiness checklists for web applications.
-origin: ECC
----
-
-# Deployment Patterns
-
-Production deployment workflows and CI/CD best practices.
-
-## When to Activate
-
-- Setting up CI/CD pipelines
-- Dockerizing an application
-- Planning deployment strategy (blue-green, canary, rolling)
-- Implementing health checks and readiness probes
-- Preparing for a production release
-- Configuring environment-specific settings
-
-## Deployment Strategies
-
-### Rolling Deployment (Default)
-
-Replace instances gradually — old and new versions run simultaneously during rollout.
-
-```
-Instance 1: v1 → v2  (update first)
-Instance 2: v1        (still running v1)
-Instance 3: v1        (still running v1)
-
-Instance 1: v2
-Instance 2: v1 → v2  (update second)
-Instance 3: v1
-
-Instance 1: v2
-Instance 2: v2
-Instance 3: v1 → v2  (update last)
-```
-
-**Pros:** Zero downtime, gradual rollout
-**Cons:** Two versions run simultaneously — requires backward-compatible changes
-**Use when:** Standard deployments, backward-compatible changes
-
-### Blue-Green Deployment
-
-Run two identical environments. Switch traffic atomically.
-
-```
-Blue  (v1) ← traffic
-Green (v2)   idle, running new version
-
-# After verification:
-Blue  (v1)   idle (becomes standby)
-Green (v2) ← traffic
-```
-
-**Pros:** Instant rollback (switch back to blue), clean cutover
-**Cons:** Requires 2x infrastructure during deployment
-**Use when:** Critical services, zero-tolerance for issues
-
-### Canary Deployment
-
-Route a small percentage of traffic to the new version first.
-
-```
-v1: 95% of traffic
-v2:  5% of traffic  (canary)
-
-# If metrics look good:
-v1: 50% of traffic
-v2: 50% of traffic
-
-# Final:
-v2: 100% of traffic
-```
-
-**Pros:** Catches issues with real traffic before full rollout
-**Cons:** Requires traffic splitting infrastructure, monitoring
-**Use when:** High-traffic services, risky changes, feature flags
-
-## Docker
-
-### Multi-Stage Dockerfile (Node.js)
-
-```dockerfile
-# Stage 1: Install dependencies
-FROM node:22-alpine AS deps
-WORKDIR /app
-COPY package.json package-lock.json ./
-RUN npm ci --production=false
-
-# Stage 2: Build
-FROM node:22-alpine AS builder
-WORKDIR /app
-COPY --from=deps /app/node_modules ./node_modules
-COPY . .
-RUN npm run build
-RUN npm prune --production
-
-# Stage 3: Production image
-FROM node:22-alpine AS runner
-WORKDIR /app
-
-RUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001
-USER appuser
-
-COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
-COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
-COPY --from=builder --chown=appuser:appgroup /app/package.json ./
-
-ENV NODE_ENV=production
-EXPOSE 3000
-
-HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
-  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1
-
-CMD ["node", "dist/server.js"]
-```
-
-### Multi-Stage Dockerfile (Go)
-
-```dockerfile
-FROM golang:1.22-alpine AS builder
-WORKDIR /app
-COPY go.mod go.sum ./
-RUN go mod download
-COPY . .
-RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /server ./cmd/server
-
-FROM alpine:3.19 AS runner
-RUN apk --no-cache add ca-certificates
-RUN adduser -D -u 1001 appuser
-USER appuser
-
-COPY --from=builder /server /server
-
-EXPOSE 8080
-HEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http://localhost:8080/health || exit 1
-CMD ["/server"]
-```
-
-### Multi-Stage Dockerfile (Python/Django)
-
-```dockerfile
-FROM python:3.12-slim AS builder
-WORKDIR /app
-RUN pip install --no-cache-dir uv
-COPY requirements.txt .
-RUN uv pip install --system --no-cache -r requirements.txt
-
-FROM python:3.12-slim AS runner
-WORKDIR /app
-
-RUN useradd -r -u 1001 appuser
-USER appuser
-
-COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages
-COPY --from=builder /usr/local/bin /usr/local/bin
-COPY . .
-
-ENV PYTHONUNBUFFERED=1
-EXPOSE 8000
-
-HEALTHCHECK --interval=30s --timeout=3s CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health/')" || exit 1
-CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000", "--workers", "4"]
-```
-
-### Docker Best Practices
-
-```
-# GOOD practices
-- Use specific version tags (node:22-alpine, not node:latest)
-- Multi-stage builds to minimize image size
-- Run as non-root user
-- Copy dependency files first (layer caching)
-- Use .dockerignore to exclude node_modules, .git, tests
-- Add HEALTHCHECK instruction
-- Set resource limits in docker-compose or k8s
-
-# BAD practices
-- Running as root
-- Using :latest tags
-- Copying entire repo in one COPY layer
-- Installing dev dependencies in production image
-- Storing secrets in image (use env vars or secrets manager)
-```
-
-## CI/CD Pipeline
-
-### GitHub Actions (Standard Pipeline)
-
-```yaml
-name: CI/CD
-
-on:
-  push:
-    branches: [main]
-  pull_request:
-    branches: [main]
-
-jobs:
-  test:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 22
-          cache: npm
-      - run: npm ci
-      - run: npm run lint
-      - run: npm run typecheck
-      - run: npm test -- --coverage
-      - uses: actions/upload-artifact@v4
-        if: always()
-        with:
-          name: coverage
-          path: coverage/
-
-  build:
-    needs: test
-    runs-on: ubuntu-latest
-    if: github.ref == 'refs/heads/main'
-    steps:
-      - uses: actions/checkout@v4
-      - uses: docker/setup-buildx-action@v3
-      - uses: docker/login-action@v3
-        with:
-          registry: ghcr.io
-          username: ${{ github.actor }}
-          password: ${{ secrets.GITHUB_TOKEN }}
-      - uses: docker/build-push-action@v5
-        with:
-          push: true
-          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
-          cache-from: type=gha
-          cache-to: type=gha,mode=max
-
-  deploy:
-    needs: build
-    runs-on: ubuntu-latest
-    if: github.ref == 'refs/heads/main'
-    environment: production
-    steps:
-      - name: Deploy to production
-        run: |
-          # Platform-specific deployment command
-          # Railway: railway up
-          # Vercel: vercel --prod
-          # K8s: kubectl set image deployment/app app=ghcr.io/${{ github.repository }}:${{ github.sha }}
-          echo "Deploying ${{ github.sha }}"
-```
-
-### Pipeline Stages
-
-```
-PR opened:
-  lint → typecheck → unit tests → integration tests → preview deploy
-
-Merged to main:
-  lint → typecheck → unit tests → integration tests → build image → deploy staging → smoke tests → deploy production
-```
-
-## Health Checks
-
-### Health Check Endpoint
-
-```typescript
-// Simple health check
-app.get("/health", (req, res) => {
-  res.status(200).json({ status: "ok" });
-});
-
-// Detailed health check (for internal monitoring)
-app.get("/health/detailed", async (req, res) => {
-  const checks = {
-    database: await checkDatabase(),
-    redis: await checkRedis(),
-    externalApi: await checkExternalApi(),
-  };
-
-  const allHealthy = Object.values(checks).every(c => c.status === "ok");
-
-  res.status(allHealthy ? 200 : 503).json({
-    status: allHealthy ? "ok" : "degraded",
-    timestamp: new Date().toISOString(),
-    version: process.env.APP_VERSION || "unknown",
-    uptime: process.uptime(),
-    checks,
-  });
-});
-
-async function checkDatabase(): Promise<HealthCheck> {
-  try {
-    await db.query("SELECT 1");
-    return { status: "ok", latency_ms: 2 };
-  } catch (err) {
-    return { status: "error", message: "Database unreachable" };
-  }
-}
-```
-
-### Kubernetes Probes
-
-```yaml
-livenessProbe:
-  httpGet:
-    path: /health
-    port: 3000
-  initialDelaySeconds: 10
-  periodSeconds: 30
-  failureThreshold: 3
-
-readinessProbe:
-  httpGet:
-    path: /health
-    port: 3000
-  initialDelaySeconds: 5
-  periodSeconds: 10
-  failureThreshold: 2
-
-startupProbe:
-  httpGet:
-    path: /health
-    port: 3000
-  initialDelaySeconds: 0
-  periodSeconds: 5
-  failureThreshold: 30    # 30 * 5s = 150s max startup time
-```
-
-## Environment Configuration
-
-### Twelve-Factor App Pattern
-
-```bash
-# All config via environment variables — never in code
-DATABASE_URL=postgres://user:pass@host:5432/db
-REDIS_URL=redis://host:6379/0
-API_KEY=${API_KEY}           # injected by secrets manager
-LOG_LEVEL=info
-PORT=3000
-
-# Environment-specific behavior
-NODE_ENV=production          # or staging, development
-APP_ENV=production           # explicit app environment
-```
-
-### Configuration Validation
-
-```typescript
-import { z } from "zod";
-
-const envSchema = z.object({
-  NODE_ENV: z.enum(["development", "staging", "production"]),
-  PORT: z.coerce.number().default(3000),
-  DATABASE_URL: z.string().url(),
-  REDIS_URL: z.string().url(),
-  JWT_SECRET: z.string().min(32),
-  LOG_LEVEL: z.enum(["debug", "info", "warn", "error"]).default("info"),
-});
-
-// Validate at startup — fail fast if config is wrong
-export const env = envSchema.parse(process.env);
-```
-
-## Rollback Strategy
-
-### Instant Rollback
-
-```bash
-# Docker/Kubernetes: point to previous image
-kubectl rollout undo deployment/app
-
-# Vercel: promote previous deployment
-vercel rollback
-
-# Railway: redeploy previous commit
-railway up --commit <previous-sha>
-
-# Database: rollback migration (if reversible)
-npx prisma migrate resolve --rolled-back <migration-name>
-```
-
-### Rollback Checklist
-
-- [ ] Previous image/artifact is available and tagged
-- [ ] Database migrations are backward-compatible (no destructive changes)
-- [ ] Feature flags can disable new features without deploy
-- [ ] Monitoring alerts configured for error rate spikes
-- [ ] Rollback tested in staging before production release
-
-## Production Readiness Checklist
-
-Before any production deployment:
-
-### Application
-- [ ] All tests pass (unit, integration, E2E)
-- [ ] No hardcoded secrets in code or config files
-- [ ] Error handling covers all edge cases
-- [ ] Logging is structured (JSON) and does not contain PII
-- [ ] Health check endpoint returns meaningful status
-
-### Infrastructure
-- [ ] Docker image builds reproducibly (pinned versions)
-- [ ] Environment variables documented and validated at startup
-- [ ] Resource limits set (CPU, memory)
-- [ ] Horizontal scaling configured (min/max instances)
-- [ ] SSL/TLS enabled on all endpoints
-
-### Monitoring
-- [ ] Application metrics exported (request rate, latency, errors)
-- [ ] Alerts configured for error rate > threshold
-- [ ] Log aggregation set up (structured logs, searchable)
-- [ ] Uptime monitoring on health endpoint
-
-### Security
-- [ ] Dependencies scanned for CVEs
-- [ ] CORS configured for allowed origins only
-- [ ] Rate limiting enabled on public endpoints
-- [ ] Authentication and authorization verified
-- [ ] Security headers set (CSP, HSTS, X-Frame-Options)
-
-### Operations
-- [ ] Rollback plan documented and tested
-- [ ] Database migration tested against production-sized data
-- [ ] Runbook for common failure scenarios
-- [ ] On-call rotation and escalation path defined

package/.kimi/skills/design-system/SKILL.md

@@ -1,82 +0,0 @@
----
-name: design-system
-description: Use this skill to generate or audit design systems, check visual consistency, and review PRs that touch styling.
-origin: ECC
----
-
-# Design System — Generate & Audit Visual Systems
-
-## When to Use
-
-- Starting a new project that needs a design system
-- Auditing an existing codebase for visual consistency
-- Before a redesign — understand what you have
-- When the UI looks "off" but you can't pinpoint why
-- Reviewing PRs that touch styling
-
-## How It Works
-
-### Mode 1: Generate Design System
-
-Analyzes your codebase and generates a cohesive design system:
-
-```
-1. Scan CSS/Tailwind/styled-components for existing patterns
-2. Extract: colors, typography, spacing, border-radius, shadows, breakpoints
-3. Research 3 competitor sites for inspiration (via browser MCP)
-4. Propose a design token set (JSON + CSS custom properties)
-5. Generate DESIGN.md with rationale for each decision
-6. Create an interactive HTML preview page (self-contained, no deps)
-```
-
-Output: `DESIGN.md` + `design-tokens.json` + `design-preview.html`
-
-### Mode 2: Visual Audit
-
-Scores your UI across 10 dimensions (0-10 each):
-
-```
-1. Color consistency — are you using your palette or random hex values?
-2. Typography hierarchy — clear h1 > h2 > h3 > body > caption?
-3. Spacing rhythm — consistent scale (4px/8px/16px) or arbitrary?
-4. Component consistency — do similar elements look similar?
-5. Responsive behavior — fluid or broken at breakpoints?
-6. Dark mode — complete or half-done?
-7. Animation — purposeful or gratuitous?
-8. Accessibility — contrast ratios, focus states, touch targets
-9. Information density — cluttered or clean?
-10. Polish — hover states, transitions, loading states, empty states
-```
-
-Each dimension gets a score, specific examples, and a fix with exact file:line.
-
-### Mode 3: AI Slop Detection
-
-Identifies generic AI-generated design patterns:
-
-```
-- Gratuitous gradients on everything
-- Purple-to-blue defaults
-- "Glass morphism" cards with no purpose
-- Rounded corners on things that shouldn't be rounded
-- Excessive animations on scroll
-- Generic hero with centered text over stock gradient
-- Sans-serif font stack with no personality
-```
-
-## Examples
-
-**Generate for a SaaS app:**
-```
-/design-system generate --style minimal --palette earth-tones
-```
-
-**Audit existing UI:**
-```
-/design-system audit --url http://localhost:3000 --pages / /pricing /docs
-```
-
-**Check for AI slop:**
-```
-/design-system slop-check
-```