📦 deps(thirdparty): update snapshots

antigravity-awesome-skills/skills/ecl-harness-engineer/agents/analyzer.md

@@ -0,0 +1,119 @@
+# Code Architecture Analysis Agent
+
+You are analyzing a codebase to understand its architecture for building agent harness infrastructure.
+
+## Your Task
+
+Produce a complete architectural analysis that can be used by other agents to create documentation, linters, and configuration.
+
+## Step-by-Step
+
+### 1. Identify Tech Stack
+
+```bash
+ls go.mod package.json requirements.txt pyproject.toml Cargo.toml 2>/dev/null
+```
+
+Record: language, version, key dependencies.
+
+### 2. Map Directory Structure
+
+```bash
+find . -type f \( -name "*.go" -o -name "*.ts" -o -name "*.js" -o -name "*.py" -o -name "*.rs" \) \
+  ! -path './.git/*' ! -path './node_modules/*' ! -path './vendor/*' | head -100
+```
+
+Identify the organizational pattern (cmd/ + internal/, src/ + lib/, etc.)
+
+### 3. Build Layer Hierarchy from Imports
+
+This is the most critical step. Analyze actual import relationships:
+
+**Go**: `grep -r '"module-path/' --include="*.go"` or `go list -json ./...`
+**TypeScript**: `grep -r "from ['\"]\.\.?/" --include="*.ts" --include="*.tsx"`
+**Python**: `grep -r "^from \." --include="*.py"`
+
+Assign layers bottom-up:
+- Layer 0: Packages with ZERO internal imports
+- Layer N: Packages that only import from layers < N
+
+Record every package and its layer assignment.
+
+### 4. Detect Circular Dependencies
+
+If Package A imports Package B AND Package B imports Package A → P0 issue.
+
+Record:
+- Files involved (with line numbers)
+- Type: direct vs transitive
+- Suggested fix
+
+### 5. Extract Key Interfaces
+
+Search for interface/abstract definitions:
+- Go: `grep -r "type.*interface" --include="*.go"`
+- TypeScript: `grep -r "interface\|abstract class" --include="*.ts"`
+- Python: `grep -r "@abstractmethod" --include="*.py"`
+
+For each key interface, record: name, location (file:line), methods, implementations, usage sites.
+
+### 6. Trace Critical Code Paths
+
+Pick 3-5 representative paths (happy path, error path, complex flow, background job).
+
+For each, trace from entry point through all layers:
+```
+[file:line] function_name()
+    ↓ calls
+[file:line] another_function()
+    ↓ returns
+...
+```
+
+### 7. Catalog Error Handling Patterns
+
+Identify:
+- Typed errors vs strings?
+- Error wrapping convention?
+- Error code registry?
+- Structured logging?
+- Retry logic?
+
+## Output Format
+
+Save results to `harness/.analysis/architecture.json`:
+
+```json
+{
+  "tech_stack": {
+    "language": "Go",
+    "version": "1.22",
+    "module_path": "github.com/org/project",
+    "key_dependencies": ["chi", "pgx", "zap"]
+  },
+  "layers": [
+    {"level": 0, "packages": ["internal/types", "internal/errors"], "description": "Core types, zero internal deps"},
+    {"level": 1, "packages": ["internal/utils", "internal/logging"], "description": "Utilities, only imports L0"},
+    {"level": 2, "packages": ["internal/core", "internal/auth"], "description": "Business logic"}
+  ],
+  "circular_dependencies": [
+    {"pkg_a": "internal/auth", "pkg_b": "internal/core", "files": ["auth/middleware.go:15", "core/service.go:23"], "suggested_fix": "Extract shared interface"}
+  ],
+  "key_interfaces": [
+    {"name": "UserService", "location": "internal/core/user.go:10-25", "methods": ["GetUser", "CreateUser"], "implementations": ["internal/core/user_impl.go"]}
+  ],
+  "code_paths": [
+    {"name": "Create User", "trigger": "POST /api/users", "flow": ["cmd/api.go:45", "core/user.go:30", "storage/user.go:15"]}
+  ],
+  "error_patterns": {
+    "style": "typed_errors",
+    "wrapping": true,
+    "structured_logging": true,
+    "error_registry": "internal/errors/codes.go"
+  },
+  "total_files": 45,
+  "total_lines": 3500
+}
+```
+
+Also write a human-readable summary to `harness/.analysis/architecture-summary.md`.

antigravity-awesome-skills/skills/ecl-harness-engineer/agents/auditor.md

@@ -0,0 +1,212 @@
+# Harness State Audit Agent
+
+You are auditing the existing harness infrastructure of a codebase to identify gaps and issues.
+
+## Your Task
+
+Produce a comprehensive audit report showing what exists, what's missing, and what's broken.
+
+## Profile Detection
+
+Audit the project as `core` unless the repository or user request explicitly enables advanced
+agent-platform capabilities such as agent evals, execution traces, long-term memory, checkpoints,
+or metrics.
+
+- **Core profile**: score documentation, linters, environment/config, integration, and ECL change
+  system, including lightweight auto-evolve threshold checking. Do not penalize missing `harness/eval`, `harness/trace`, `harness/memory`,
+  `harness/checkpoints`, or `harness/metrics`.
+- **Advanced profile**: run the core audit plus the advanced eval and quality automation checks.
+
+## Audit Dimensions
+
+### 1. Documentation (Weight: 25%)
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| AGENTS.md exists | `test -f AGENTS.md` | File exists |
+| AGENTS.md size | `wc -l AGENTS.md` | 80-120 lines |
+| AGENTS.md has numbered sections | Count `##` headers | ≥ 5 sections |
+| ARCHITECTURE.md exists | `test -f docs/ARCHITECTURE.md` | File exists |
+| ARCHITECTURE.md has Mermaid diagrams | `grep 'mermaid' docs/ARCHITECTURE.md` | At least 1 |
+| Layer claims are accurate | Cross-reference imports | No false claims |
+| DEVELOPMENT.md commands work | Spot-check 2-3 commands | Commands succeed |
+| Design docs exist (not just index) | `find docs/design-docs -name "*.md" ! -name "index.md"` | ≥ 2 files |
+| All doc links are valid | Check `[text](path)` references | No broken links |
+| ECL doc exists | `test -f docs/ECL.md` | File exists |
+| ECL doc defines lifecycle | Read docs/ECL.md | active/parking/archive and update protocol documented |
+| STATUS handoff exists | `test -f docs/STATUS.md` | File exists when ECL is enabled |
+| STATUS priority is correct | Read docs/STATUS.md and AGENTS.md | Active change overrides STATUS; STATUS is used only when no active exists |
+
+### 2. Linters (Weight: 20%)
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| lint-deps script exists | `test -f scripts/lint-deps*` | File exists |
+| lint-quality script exists | `test -f scripts/lint-quality*` | File exists |
+| Layer map covers all packages | Compare map vs `go list ./...` | 100% coverage |
+| Can detect real violations | Create test case | Violation caught |
+| Error messages are agent-actionable | Read 5 error messages | WHAT + WHY + HOW |
+| `make lint-arch` passes | Run it | Exit code 0 |
+
+### 3. Eval System (Advanced profile only; Weight: 20% when enabled)
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| Eval directory exists | `test -d harness/eval` | Directory exists |
+| Eval datasets present | `find harness/eval/datasets -name "*.json"` | ≥ 5 tasks |
+| Categories covered | Count unique categories | ≥ 3 |
+| Tasks reference real files | Spot-check file paths | Valid references |
+| Task freshness | Check git dates | Updated within 90 days |
+
+### 4. Environment & Config (Weight: 15%)
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| environment.json exists | `test -f harness/config/environment.json` | File exists (if project has external deps) |
+| Setup scripts exist | `test -f harness/scripts/setup-env.sh` | File exists |
+| Scripts are executable | `test -x harness/scripts/*.sh` | Executable |
+| No hardcoded secrets | `grep -r "password\|secret\|key=" harness/config/` | Uses ${VAR} references |
+
+### 5. Integration (Weight: 10%)
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| Makefile has lint-arch target | `grep 'lint-arch' Makefile` | Target exists |
+| Build passes | `make build` or equivalent | Exit code 0 |
+| CI config exists | `test -f .github/workflows/ci.yml` | File exists |
+
+### 6. Quality Automation (Advanced profile only; Weight: 10% when enabled)
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| Observability structure | `test -d harness/trace` | Directory exists |
+| Memory structure | `test -d harness/memory` | Directory exists |
+| Checkpointing support | `test -d harness/checkpoints` | Directory exists |
+
+### 7. ECL Change System (Weight: report separately)
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| changes directories exist | `test -d harness/changes/active && test -d harness/changes/parking && test -d harness/changes/archive` | Directories exist |
+| change templates exist | `test -f harness/templates/change/summary.md` etc. | New harnesses have summary/spec/plan/tasks/reviews templates; old archives may remain 4-file |
+| harness-change script exists | `test -f scripts/harness-change.*` | One selected command-surface implementation exists |
+| lint-ecl exists | `test -f scripts/lint-ecl.*` | One selected command-surface implementation exists |
+| lint-encoding exists | `test -f scripts/lint-encoding.*` | One selected command-surface implementation exists |
+| INDEX.json is generated | Run generated `harness-change reindex` command or dry-run equivalent | Index matches parking/archive |
+| active is single | Inspect changes dir | No multiple active task directories |
+| archive loading is selective | Read AGENTS.md/docs/ECL.md | History loads through STATUS/INDEX; no default full archive load |
+
+### 8. Auto-Evolve (Core profile; Weight: report separately)
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| evolution state exists | `test -f harness/evolution/state.json` | File exists with enabled, threshold, window, last_evolved_archive_count |
+| harness-evolve script exists | `test -f scripts/harness-evolve.*` | One selected command-surface implementation exists |
+| close/reindex trigger check | Read `scripts/harness-change.*` | `close` and `reindex` run `harness-evolve check` or equivalent |
+| pending is bounded | Read generated docs/scripts | pending lists candidate archive summaries, not full archive contents |
+| active work has priority | Read AGENTS.md/docs/ECL.md | pending is deferred when active change exists |
+| no advanced dirs by default | Inspect harness tree | no eval/trace/memory/checkpoints/metrics unless explicitly requested |
+| ratchet rule documented | Read docs/ECL.md | keep only if score improves and verification passes; otherwise revert |
+| independent scoring documented | Read docs/ECL.md and proposals | auto-apply requires an auditor/subagent independent review |
+| proposal-first flow | Inspect `harness/evolution/proposals/` | accepted/rejected candidates are separated before file edits |
+| results log decisions | Read `harness/evolution/results.tsv` | status is one of keep/revert/rejected/noop and eval_mode is present |
+
+## Auto-Evolve Independent Review
+
+When asked to score an auto-evolve proposal, act as an independent evaluator. Do not generate or
+edit the delta you are scoring. Return a concise decision object and a short explanation.
+
+Score out of 100:
+
+| Dimension | Weight | Pass Criteria |
+|-----------|-------:|---------------|
+| Evidence grounding | 30 | Accepted candidates cite specific archived summaries, reviews, or validation notes |
+| Project relevance | 25 | Accepted candidates map to current project modules, files, commands, failures, or user corrections |
+| Mechanical enforceability | 15 | Important rules become lint/test/CI checks or explicit acceptance gates |
+| Regression safety | 20 | Proposed delta does not weaken harness checks or business gates |
+| Context cost | 10 | AGENTS.md stays concise and archive loading remains bounded |
+
+Hard rejection conditions:
+
+- No archived change evidence for an accepted candidate.
+- Candidate is generic best practice, article advice, or model inference without project evidence.
+- Candidate cannot name affected project files, modules, commands, failures, or user corrections.
+- Candidate would default-create `harness/eval`, `harness/trace`, `harness/state`,
+  `harness/checkpoints`, `harness/memory`, or `harness/metrics`.
+- Candidate would put rejected material into AGENTS.md, ECL, STATUS, lint, or CI.
+
+Decision rules:
+
+- `keep`: score >= 80, hard gates pass, and validation plan is adequate.
+- `rejected`: hard gate fails or score < 80 before file edits.
+- `noop`: no accepted candidates with enough evidence.
+- `revert`: file edits were applied but validation or independent review fails.
+
+Output format:
+
+```json
+{
+  "decision": "keep",
+  "score": 86,
+  "eval_mode": "independent_review",
+  "dimension_scores": {
+    "evidence_grounding": 27,
+    "project_relevance": 23,
+    "mechanical_enforceability": 12,
+    "regression_safety": 16,
+    "context_cost": 8
+  },
+  "accepted": ["quality gate requires nonzero test count"],
+  "rejected": ["generic prompt advice with no project evidence"],
+  "required_validation": ["lint-ecl", "lint-encoding", "relevant business gate"],
+  "reason": "Accepted candidate cites two archived changes and maps to the existing test command."
+}
+```
+
+## Scoring
+
+For each dimension, score 0-10:
+- 10: All checks pass, high quality
+- 7-9: Most checks pass, minor gaps
+- 4-6: Some checks pass, significant gaps
+- 1-3: Few checks pass, major gaps
+- 0: Dimension entirely missing
+
+For core-profile projects, exclude advanced-only dimensions from the weighted overall score instead
+of scoring them as zero. For advanced-profile projects, include them and report missing directories
+or protocols as gaps.
+
+## Output Format
+
+Save results to `harness/.analysis/audit.json`:
+
+```json
+{
+  "profile": "core",
+  "overall_score": 6.5,
+  "dimensions": {
+    "documentation": {"score": 7, "weight": 25, "checks_passed": 7, "checks_total": 9},
+    "linters": {"score": 5, "weight": 20, "checks_passed": 3, "checks_total": 6},
+    "environment": {"score": 8, "weight": 15, "checks_passed": 4, "checks_total": 5},
+    "integration": {"score": 9, "weight": 10, "checks_passed": 3, "checks_total": 3},
+    "ecl_changes": {"score": 4, "weight": 0, "checks_passed": 3, "checks_total": 7},
+    "auto_evolve": {"score": 6, "weight": 0, "checks_passed": 4, "checks_total": 7}
+  },
+  "advanced_dimensions": {
+    "evals": {"enabled": false, "reason": "advanced profile not requested"},
+    "quality_automation": {"enabled": false, "reason": "advanced profile not requested"}
+  },
+  "gaps": [
+    {"priority": "P0", "dimension": "documentation", "issue": "ARCHITECTURE.md claims 3 layers but code has 4", "fix": "Regenerate from actual imports"},
+    {"priority": "P1", "dimension": "linters", "issue": "lint-deps missing 5 packages", "fix": "Add internal/cache, internal/auth to layer map"},
+    {"priority": "P1", "dimension": "ecl_changes", "issue": "INDEX.json is hand-maintained or stale", "fix": "Generate it from archive/parking via the generated harness-change reindex command"}
+  ],
+  "strengths": [
+    "Build passes cleanly",
+    "CI properly configured",
+    "Error handling is consistent"
+  ]
+}
+```
+
+Also write human-readable audit to `harness/.analysis/audit-summary.md`.

antigravity-awesome-skills/skills/ecl-harness-engineer/agents/creator-config.md

@@ -0,0 +1,343 @@
+# Config & Environment Creation Agent
+
+You are creating or updating harness configuration and environment files.
+
+## Input
+
+You will receive:
+- Environment analysis (from `harness/.analysis/environment.json`)
+- Architecture data (from `harness/.analysis/architecture.json`)
+- Existing state (from `harness/.analysis/audit.json`)
+- Delta list of files to create/update
+
+## Files You Create/Update
+
+### harness/config/environment.json
+
+The runtime ecosystem contract. Describes what the application needs to run.
+
+**REQUIRED FIELDS** (functional verification depends on these):
+- `runtime.dev_command` — How to start the server in dev mode
+- `runtime.build_command` — How to build the project
+- `test_environment.env_vars` — Environment variables for test mode
+- `functional_scenarios[]` — List of verification scenarios
+
+```json
+{
+  "runtime": {
+    "language": "go",
+    "version": "1.22",
+    "build_command": "go build ./...",
+    "dev_command": "go run main.go server -c config/server.toml",
+    "test_command": "go test ./...",
+    "binary_path": "./qts"
+  },
+  "databases": [
+    {
+      "type": "postgresql",
+      "env_vars": {"DATABASE_URL": "postgres://..."},
+      "docker": {"image": "postgres:16", "port": 5432},
+      "test_alternative": "SQLite in-memory"
+    }
+  ],
+  "services": [
+    {"type": "redis", "env_vars": {"REDIS_URL": "redis://localhost:6379"}}
+  ],
+  "secrets": [
+    {"name": "JWT_SECRET", "description": "JWT signing key", "test_value": "test-secret-do-not-use-in-prod"}
+  ],
+  "test_environment": {
+    "env_vars": {
+      "GIN_MODE": "release",
+      "ENV_TAG": "test",
+      "LOG_LEVEL": "error"
+    }
+  },
+  "functional_scenarios": [
+    {
+      "name": "health_check",
+      "description": "Verify server starts and health endpoint responds correctly",
+      "prerequisites": ["postgresql", "redis"],
+      "steps": [
+        "Start server with runtime.dev_command",
+        "Wait for server to be ready (GET /healthz returns 200)",
+        "Verify health response contains status: up"
+      ],
+      "expected_outcome": "Server is healthy and all dependencies connected"
+    },
+    {
+      "name": "basic_crud_flow",
+      "description": "Create, read, update, delete a resource via API",
+      "prerequisites": ["postgresql"],
+      "steps": [
+        "POST /api/v1/resources with valid payload -> 201",
+        "GET /api/v1/resources/:id -> 200 with matching data",
+        "PUT /api/v1/resources/:id -> 200",
+        "DELETE /api/v1/resources/:id -> 204"
+      ],
+      "expected_outcome": "CRUD operations work correctly"
+    }
+  ],
+  "scripts": {
+    "setup": "harness/scripts/setup-env.sh",
+    "start": "harness/scripts/start-server.sh",
+    "teardown": "harness/scripts/teardown-env.sh"
+  }
+}
+```
+
+Follow `references/environment-detection-guide.md` for detection strategies.
+
+### harness/scripts/setup-env.sh
+
+Start external dependencies (DB, Redis, etc.):
+
+```bash
+#!/bin/bash
+set -euo pipefail
+
+# Start PostgreSQL
+docker run -d --name harness-postgres \
+  -p 5432:5432 \
+  -e POSTGRES_PASSWORD=testpass \
+  postgres:16
+
+# Wait for ready
+until docker exec harness-postgres pg_isready; do sleep 1; done
+
+echo "✓ Environment ready"
+```
+
+If `docker-compose.yml` already exists, create a thin wrapper instead.
+
+### harness/scripts/start-server.sh
+
+Start the application with test environment:
+
+```bash
+#!/bin/bash
+set -euo pipefail
+
+export PORT=8081
+export ENV=test
+export DATABASE_URL="postgres://postgres:testpass@localhost:5432/testdb?sslmode=disable"
+
+# Start server
+go run cmd/api/main.go &
+SERVER_PID=$!
+
+# Wait for ready
+for i in $(seq 1 30); do
+  if curl -s http://localhost:$PORT/health > /dev/null 2>&1; then
+    echo "✓ Server ready (PID: $SERVER_PID)"
+    exit 0
+  fi
+  sleep 1
+done
+
+echo "✗ Server failed to start"
+exit 1
+```
+
+### harness/scripts/teardown-env.sh
+
+Stop and cleanup:
+
+```bash
+#!/bin/bash
+docker stop harness-postgres 2>/dev/null || true
+docker rm harness-postgres 2>/dev/null || true
+echo "✓ Cleaned up"
+```
+
+### Makefile Targets
+
+Ensure these targets exist:
+
+```makefile
+.PHONY: lint-arch lint-ecl lint-encoding verify-harness build test setup-env start-server teardown-env
+
+lint-arch:
+	./scripts/lint-deps
+	./scripts/lint-quality
+
+lint-ecl:
+	{ecl_lint_command}
+
+lint-encoding:
+	{encoding_lint_command}
+
+verify-harness: lint-ecl lint-encoding lint-arch
+
+build:
+	{appropriate build command}
+
+test:
+	{appropriate test command}
+
+setup-env:
+	./harness/scripts/setup-env.sh
+
+start-server:
+	./harness/scripts/start-server.sh
+
+teardown-env:
+	./harness/scripts/teardown-env.sh
+```
+
+### .github/workflows/ci.yml
+
+Basic CI that runs build, lint, and test:
+
+```yaml
+name: CI
+on: [push, pull_request]
+jobs:
+  check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-{lang}@v5
+        with:
+          {lang}-version: '{version}'
+      - run: make build
+      - run: make lint-arch
+      - run: make test
+```
+
+CI must be strict by default. Include the project's normal business gates (`lint`,
+`typecheck`, `test`, `build`, and nested package builds when detected) plus harness checks.
+Do not remove or skip business gates because the baseline is already red; instead report those
+failures as pre-existing project debt in the final handoff. Generate staged or relaxed CI only
+when the user explicitly requests that tradeoff.
+
+For TypeScript/Node.js projects, prefer package-manager scripts and Node setup over Makefile-only
+CI. Use the adapter in `references/adapters/typescript.md` to detect npm/pnpm/yarn/bun and generate
+commands such as `npm run lint:harness`, `npm run lint:arch`, `npm run typecheck`, `npm test`,
+`npm run build`, and nested package build steps when present.
+
+### Harness Directory Structure
+
+Create the default core harness directory tree:
+
+```
+harness/
+├── config/
+│   └── environment.json
+├── changes/
+│   ├── active/
+│   ├── parking/
+│   ├── archive/
+│   └── INDEX.json
+├── evolution/
+│   ├── state.json
+│   ├── results.tsv
+│   └── proposals/
+├── templates/
+│   └── change/
+│       ├── summary.md
+│       ├── spec.md
+│       ├── plan.md
+│       ├── tasks.md
+│       └── reviews/
+│           └── review.md
+├── scripts/
+│   ├── setup-env.sh
+│   ├── start-server.sh
+│   └── teardown-env.sh
+```
+
+Initialize `harness/evolution/state.json`:
+
+```json
+{
+  "enabled": true,
+  "threshold": 5,
+  "window": 10,
+  "last_evolved_archive_count": 0,
+  "last_evolved_change_id": null,
+  "last_score": null,
+  "last_run_at": null,
+  "pending": false
+}
+```
+
+Initialize `harness/evolution/results.tsv` with this header:
+
+```tsv
+timestamp	change_id	old_score	new_score	status	dimension	note	eval_mode
+```
+
+Allowed status values are `keep`, `revert`, `rejected`, and `noop`. Allowed eval modes are
+`independent_review`, `dry_run`, and `full_test`. Use `dry_run` when no independent auditor/subagent
+is available; do not auto-apply harness deltas in that mode.
+
+Do not create empty advanced directories by default.
+
+Create optional advanced directories only when the confirmed scope or user request explicitly
+requires that capability:
+
+```
+harness/
+├── eval/          # Agent evaluation datasets and runner inputs
+├── trace/         # Agent execution traces
+├── state/         # Runtime state for external executors
+├── checkpoints/   # Resumable execution checkpoints
+├── memory/        # Long-term agent memory experiments
+│   ├── episodes/
+│   ├── knowledge/
+│   └── procedures/
+└── metrics/       # Execution, quality, and cost metrics
+```
+
+Advanced directories must come with a read/write protocol and validation command. If no protocol is
+defined, leave the capability out of the generated harness.
+
+## Scripts Must Be
+
+- `chmod +x` — executable
+- Self-contained — no external dependencies beyond Docker
+- Idempotent — safe to run multiple times
+- With error handling — `set -euo pipefail`
+
+## ECL Change Management Scripts
+
+Create ECL scripts for the selected command surface from `references/ecl-harness.md`.
+PowerShell, Bash, Node, and Python are equivalent profiles only if they implement the same commands
+and invariants. If the project rejects `.ps1`, do not generate PowerShell as the only entrypoint.
+For Windows projects using Bash, document Git Bash, WSL, MSYS2, or CI Linux shell as a prerequisite.
+Select the profile automatically from project evidence; ask the user only when evidence conflicts or
+no supported command surface is inferable.
+
+- `scripts/harness-change.{ps1|sh|mjs|py}`: implements `new`, `status`, `validate`, `park`, `resume`, `close`, `search`, `context`, and `reindex`.
+- `scripts/harness-evolve.{ps1|sh|mjs|py}`: implements `check`, `collect`, and `mark-complete` for default auto-evolve threshold checks.
+- `scripts/lint-ecl.{ps1|sh|mjs|py}`: validates active change structure, `docs/STATUS.md` presence, `plan.md`, completed validation, pending task consistency, spec clarification gates, plan review gates, task id formatting, and generated index freshness.
+- `scripts/lint-encoding.{ps1|sh|mjs|py}`: scans source/docs for mojibake markers and UTF-8 risks.
+
+Rules:
+- `INDEX.json` is derived from `parking/*/summary.md` and `archive/*/summary.md`; agents must not hand-edit it.
+- `park`, `close`, `resume`, and `reindex` must rebuild `INDEX.json`.
+- `close` and `reindex` must run `harness-evolve check`; the evolution script may create
+  `harness/evolution/pending.md`, but it must not rewrite docs, scripts, STATUS, or change files.
+- Hook/CI integration may run validation, but must not automatically write docs, update `docs/STATUS.md`, or move changes.
+- `harness-change context` should list active change files when present; if no active change
+  exists, it should list `harness/evolution/pending.md` before `docs/STATUS.md` when pending
+  evolution exists. It must not print or load all archive files.
+- Auto-evolve is core lightweight infrastructure. It must not create `harness/eval`,
+  `harness/trace`, `harness/state`, `harness/checkpoints`, `harness/memory`, or
+  `harness/metrics` unless the user explicitly requested those advanced capabilities.
+- Wire Makefile/package scripts/CI to the selected entrypoint, for example
+  `bash scripts/lint-ecl.sh` for Bash or `{pkg_manager} run lint:harness` for package scripts.
+- If the PowerShell profile is selected, detect whether `pwsh` exists before documenting or wiring
+  commands. If `pwsh` is unavailable, use `powershell -NoProfile -ExecutionPolicy Bypass`.
+- Keep PowerShell profile scripts compatible with Windows PowerShell 5.1. Avoid ambiguous overloads such as
+  `TrimStart(".\")`; use typed arguments such as `[char[]]@(".", "\")`.
+- Avoid non-ASCII mojibake marker literals in PowerShell templates. Use Unicode codepoints or another
+  PowerShell 5.1-safe representation so the script still parses on legacy Windows code pages.
+
+## Verification Config Rule
+
+`harness/config/environment.json` is the static runtime contract created by ecl-harness-engineer.
+Do not create `harness/config/verify.json` or `harness/config/validate.json`; task-specific
+verification plans are generated later by the executor/runtime from `environment.json` plus
+the active change context.

antigravity-awesome-skills/skills/ecl-harness-engineer/agents/creator-docs.md

@@ -0,0 +1,201 @@
+# Documentation Creation Agent
+
+You are creating or updating harness documentation files for a codebase.
+
+## Input
+
+You will receive:
+- Architecture analysis data (from `harness/.analysis/architecture.json`)
+- Audit data showing what exists and what's missing (from `harness/.analysis/audit.json`)
+- Delta list of files to create/update
+
+## Files You May Create/Update
+
+### AGENTS.md
+
+The project entry map for AI agents. This is the most important file. It must help a
+new agent understand the target project first, then explain the harness workflow.
+
+**Target**: 80-120 lines. This is a map, not a manual.
+
+**Structure**:
+```
+Line 1-15:   Project snapshot: what it is, who uses it, core workflow, runtime shape
+Line 16-35:  Core workflow/domain model: real product or system concepts
+Line 36-55:  Where to work: task-to-source map with actual directories/modules
+Line 56-75:  Context loading: AGENTS.md, docs/ECL.md, active change if present, otherwise auto-evolve pending reminder if present, otherwise STATUS, then task-specific project docs
+Line 76-95:  Development + verification commands
+Line 96-120: Safety boundaries and generated harness notes
+```
+
+**Rules**:
+- The first screen must be project-first, not harness-first. It should answer:
+  "What does this project do?", "What is the main user/system workflow?", and
+  "Where would an agent start for common changes?"
+- Extract project identity from `README.md`, entry points, route files, schemas/models,
+  package manifests, and key source directories. Do not infer only from harness files.
+- Include real product/domain concepts when they exist: workflows, entities, API resources,
+  user-facing modules, jobs, commands, or data models.
+- Harness/ECL belongs in context-loading or development-discipline sections. It must not
+  dominate Quick Start or replace project knowledge.
+- Project identity and ECL constraints must not compete: keep the first screen project-first,
+  but make context loading preserve ECL priority. The order must be `AGENTS.md`,
+  `docs/ECL.md`, active change files when present, otherwise read `harness/evolution/pending.md`
+  as a maintenance reminder when it exists, otherwise `docs/STATUS.md`, then README/architecture/design/reference docs.
+- State that active change constraints are the current task source of truth and override
+  generic project guidance and `docs/STATUS.md` for that task.
+- State that `docs/STATUS.md` is a soft handoff file used only when no active change exists.
+  It should point to recent archive context, but it must not trigger default full-archive loading.
+- State that `harness/evolution/pending.md`, when present and no active change exists, should be
+  read before ordinary STATUS resume work as pending maintenance. Reading it does not start
+  auto-evolve, must not block ordinary user work, and should not cause full-archive loading. Codex
+  should ask whether to handle the pending maintenance now unless the user already prioritized the
+  current task.
+- Historical archive loading must be selective: start from `docs/STATUS.md` paths or
+  `harness/changes/INDEX.json`, read archived `summary.md` first, and read spec/plan/tasks/reviews
+  only for debugging, review, or explicit resume work.
+- Never write skill-internal boundaries into the target project. Do not add sections or
+  sentences that describe this skill's own execution limits as if they were project rules.
+- Safety boundaries must be project-level: secrets, generated outputs, uploads, unrelated
+  user edits, migrations, and verification discipline. Agents may modify business code when
+  the user's task requires it.
+- Every link must point to a doc that actually exists
+- Include real package names from architecture analysis
+- Don't embed detailed explanations — link to docs/
+- Link to `docs/ECL.md` for the change lifecycle and context loading protocol
+- Mention `harness/changes/active/` as the current task context, not as a manual
+- Keep only a short change trigger in AGENTS.md; put the detailed lifecycle in `docs/ECL.md`.
+  Typical triggers: APIs, database schema, architecture, permissions, cross-module behavior,
+  multi-file changes, or other non-trivial work.
+
+### docs/ECL.md
+
+The project operating manual for Evolution Constraint Language (ECL).
+
+**Must include**:
+- When to create a change and when small fixes can skip it
+- Small Change vs Structured Change: small low-risk edits may skip active changes; structured work
+  uses active change files and review gates
+- A compact decision tree: existing active change wins; obvious copy/comment/README/local single-file
+  fixes are Small; APIs/data/permissions/architecture/multi-module/runtime/unclear work is
+  Structured; unclear impact requires read-only investigation before deciding
+- Intake Review: support requirement-first and plan-first inputs, ask at most three high-impact
+  questions per round, and record assumptions or `[NEEDS CLARIFICATION: ...]` in `spec.md`
+- Plan-first completeness rule: a complete user plan that does not conflict with repository evidence
+  should not trigger a repeated interview; conflicts or missing acceptance/security/data/compatibility
+  details return to Intake Review
+- Single-active lifecycle: `active/`, `parking/`, `archive/`
+- Stage-boundary update protocol for `summary.md`, `spec.md`, `plan.md`, `tasks.md`, and `reviews/`
+- Spec/plan separation: `spec.md` is WHAT/WHY, `plan.md` is HOW and planning-discovered spec gaps
+- Plan review gate: do not enter implementation until `summary.md` records `plan_review: approved` or `reviews/` contains an equivalent approved plan review
+- Context load order: AGENTS.md, ECL, active change, relevant docs, generated INDEX.json, selected history
+- Auto-evolve handling: `harness-change close/reindex` may generate `harness/evolution/pending.md`;
+  pending is a maintenance reminder, not a hard lock; Codex should ask whether to handle it when no
+  active change exists
+- Auto-evolve independent review boundary: generated scripts create pending context only and do not
+  spawn subagents; the Codex run handling pending evolution requests independent review when
+  available; user approval to handle pending implies permission to request auditor/subagent review
+  when available, and if the environment still requires explicit authorization Codex asks once
+  before falling back to `eval_mode=dry_run` and no auto-apply
+- Auto-evolve completion rule: once Codex starts pending evolution by creating/using an
+  `auto-evolve-harness-*` change, writing a proposal/result, or editing Harness files from pending
+  evidence, it must finish with proposal + `results.tsv` + `harness-evolve mark-complete`; otherwise
+  park/block instead of closing completed
+- Auto-evolve evidence freshness: before processing pending, rebuild `INDEX.json` and use the
+  current eligible archive window; old Candidate Archives are a trigger snapshot only
+- Failure feedback: failed tests/lints become constraints, tasks, or regression notes
+- Script commands: `harness-change new/status/validate/park/resume/close/search/context/reindex` and `harness-evolve check/collect/mark-complete`
+- Rule that `harness/changes/INDEX.json` is generated by scripts and must not be hand-edited
+
+Use `references/ecl-harness.md` for the default text and templates.
+
+### docs/STATUS.md
+
+The lightweight handoff summary for current project state. Create it when adding or updating ECL.
+
+**Target**: 40-80 lines. This is a resume map, not a changelog.
+
+**Must include**:
+- A first-line warning that active change files override this file when present
+- Current active work or "none"
+- Last completed change path, normally the archived `summary.md`
+- Next recommended work
+- Known residual risks or blockers
+- Latest quality gate state
+- Context resume instructions that point to `docs/ECL.md`, active change, `docs/STATUS.md`, and selected archive summaries
+- Auto-evolve pending status when `harness/evolution/pending.md` exists
+
+**Rules**:
+- Update `docs/STATUS.md` before closing an active change with completed work, validation,
+  risks, and next step.
+- After `harness-change close`, update it again with the final archive path.
+- If `harness/evolution/pending.md` exists after close and no active task is present, mention it as
+  pending maintenance and ask whether to handle it now unless the user task is already prioritized;
+  do not treat read-only context loading or asking as started auto-evolve.
+- Do not let CI or hooks auto-write STATUS; they may only validate it.
+- Never treat STATUS as more authoritative than `harness/changes/active/`.
+- Do not store full history in STATUS; keep formal history in `harness/changes/archive/`
+  and discover it through `harness/changes/INDEX.json`.
+
+### docs/ARCHITECTURE.md
+
+The authoritative architecture document.
+
+**Must include**:
+- Mermaid diagram generated from actual import analysis (not templates)
+- Layer table with real packages and their dependencies
+- Source citations (`> Sources: [file:line]()`) for every claim
+- Forbidden dependency rules
+
+### docs/DEVELOPMENT.md
+
+Development setup and commands.
+
+**Must include**:
+- Prerequisites (Go version, Node version, etc.)
+- Build commands that actually work
+- Test commands with explanation
+- Lint commands
+- Harness commands: `verify-harness`, `lint-ecl`, `lint-encoding`, `harness-change`
+
+### docs/design-docs/
+
+Component-level design documents.
+
+**For each key component** (from architecture analysis):
+1. `docs/design-docs/index.md` — Index table
+2. `docs/design-docs/{component}.md` — Detailed design doc
+
+**Each design doc must have**:
+- Overview
+- Architecture (with Mermaid diagram)
+- Key Interfaces (with file:line citations)
+- Execution Flow
+- Error Handling
+
+**Use templates from** `references/documentation-templates.md`.
+
+### Additional docs (as needed)
+
+- `docs/QUALITY.md` — Quality standards
+- `docs/TESTING.md` — Testing strategy
+- `docs/SECURITY.md` — Security considerations
+- `docs/PRODUCT_SENSE.md` — Product context
+- `docs/references/index.md` — Reference index
+
+## Quality Requirements
+
+| Requirement | What This Means |
+|-------------|-----------------|
+| **Source-grounded** | Every claim cites actual file:line |
+| **Real data** | Layer maps use actual packages, not placeholders |
+| **Working commands** | DEVELOPMENT.md commands actually run |
+| **No placeholders** | No "TODO: fill in later" |
+| **Numbered sections** | For stable cross-references |
+| **Generated index clarity** | Docs say INDEX.json is script-generated, not hand-maintained |
+
+## What NOT to Create
+
+- Source code files
+- Test files for business logic
+- Application entry points

antigravity-awesome-skills/skills/ecl-harness-engineer/agents/creator-linters.md

@@ -0,0 +1,123 @@
+# Linter Creation Agent
+
+You are creating or updating linter scripts for agent harness infrastructure.
+
+## Input
+
+You will receive:
+- Architecture analysis with full layer hierarchy (from `harness/.analysis/architecture.json`)
+- Existing linter state (from `harness/.analysis/audit.json`)
+- Delta list of what to create/update
+
+## Files You Create/Update
+
+### scripts/lint-deps.{ext}
+
+**Purpose**: Enforce layer boundaries — prevent forbidden imports.
+
+**Must include**:
+- Complete layer map with EVERY package from the architecture analysis
+- No blind spots — if a package exists, it must be in the layer map
+- Layer rules: Layer N can only import from layers < N
+
+**Error message format** (agent-actionable):
+
+```
+{file}:{line} imports {forbidden_package} (layer {N} → layer {M}).
+Layer {N} packages can only import from layers < {N}.
+
+Fix options:
+1. Move {logic description} to a higher layer (e.g., {suggestion})
+2. Pass the value as a parameter instead of importing directly
+3. Define an interface in layer {N} and implement in layer {M}
+```
+
+This is the most important quality requirement. An error message that only says "Forbidden import" is useless to an agent. The message must tell WHAT is wrong, WHY it matters, and HOW to fix it.
+
+### scripts/lint-quality.{ext}
+
+**Purpose**: Enforce code quality patterns.
+
+**Common rules** (customize based on codebase patterns):
+- File size limits (e.g., > 500 lines → warning)
+- Structured logging enforcement
+- Error wrapping convention
+- Naming conventions
+- Test file presence
+
+**Same error message quality**: WHAT + WHY + HOW.
+
+### scripts/lint-ecl.{ps1|sh|mjs|py}
+
+**Purpose**: Enforce ECL change lifecycle integrity.
+
+**Must check**:
+- `harness/changes/active/` has `summary.md`, `spec.md`, `plan.md`, `tasks.md`, and `reviews/` when active exists.
+- Markdown front matter status is internally consistent.
+- Active changes in `implement`, `validate`, or `done` phase have no high-impact
+  `[NEEDS CLARIFICATION: ...]` markers in `spec.md`.
+- Active changes cannot enter implementation until `plan_review` is approved in `summary.md` or an
+  equivalent approved Plan Review exists in `reviews/review.md`.
+- Executable task lines in `tasks.md` use `T###` ids, and implementation tasks include target paths
+  plus validation notes.
+- `completed` changes have validation results.
+- `tasks.md` with unexplained pending items cannot be completed.
+- `docs/STATUS.md` exists for ECL-enabled projects and clearly says active change files override it.
+- A temporary regenerated index matches `harness/changes/INDEX.json`; otherwise fail and tell the user to run the generated `scripts/harness-change.* reindex` equivalent.
+- `scripts/harness-evolve.*` and `harness/evolution/state.json` exist for core auto-evolve threshold checking.
+- If `harness/evolution/pending.md` exists, lint may report it as pending context, but must not apply or delete it automatically.
+
+### scripts/lint-encoding.{ps1|sh|mjs|py}
+
+**Purpose**: Enforce UTF-8 and prevent mojibake from being written into source or docs.
+
+**Must check**:
+- Scan text files for known mojibake markers listed in `references/ecl-harness.md`.
+- Exclude generated/vendor/cache directories.
+- Return actionable file and line messages.
+
+## Language-Specific Templates
+
+Use templates from `references/linter-templates.md` as starting points, then customize:
+
+- **Go**: Go script that parses imports, checks against layer map
+- **TypeScript/Node.js**: read `references/adapters/typescript.md` first; generate Node/TS-native scripts such as `scripts/lint-deps.mjs` and `scripts/lint-quality.mjs`, and wire them through npm/package-manager scripts
+- **Python**: Python script that parses from/import statements
+- **ECL/Encoding**: use the selected command surface profile from `references/ecl-harness.md` (`.ps1`, `.sh`, `.mjs`, or `.py`)
+
+## Critical Rules
+
+1. **Day-one pass required**: The linter MUST pass on the current codebase without errors. If the codebase has existing violations, document them in `docs/exec-plans/tech-debt-tracker.md` instead of failing the linter.
+
+2. **Complete coverage**: Every package in the codebase must appear in the layer map. Missing packages = blind spots = undetected violations.
+
+3. **Executable**: Scripts must run from the project root. Bash/Node/Python scripts should be executable when the environment supports file modes; Windows-only profiles may use explicit interpreter commands.
+
+4. **Makefile integration**: Ensure `make lint-arch` target runs these scripts.
+
+5. **Generated index, evolution, and handoff discipline**: `lint-ecl` verifies `INDEX.json` freshness, auto-evolve state presence, and `docs/STATUS.md` presence, but never rewrites those files. Rewriting belongs to the generated `harness-change reindex`, `harness-evolve check/mark-complete`, and explicit agent/human handoff updates.
+
+6. **Command surface consistency**: Select the script profile automatically from project evidence. If the project rejects `.ps1`, do not generate PowerShell as the only entrypoint. For Windows projects using Bash, document Git Bash, WSL, MSYS2, or CI Linux shell as a prerequisite. If the PowerShell profile is selected, scripts must run on Windows PowerShell 5.1 as well as PowerShell 7.
+
+7. **Strict business gates**: Do not remove or weaken existing project `lint`, `typecheck`, `test`,
+   or `build` checks to make CI pass. If those checks fail before harness creation, report them as
+   pre-existing project debt; keep the generated CI strict unless the user explicitly asks for staged rollout.
+
+## Verification
+
+After creating linters, verify:
+
+```bash
+# Linters are executable
+chmod +x scripts/lint-deps* scripts/lint-quality*
+
+# Linters pass on current codebase
+make lint-arch
+
+# ECL and encoding checks pass
+{ecl_lint_command}
+{encoding_lint_command}
+
+# Count covered packages vs total packages
+# (should be 100%)
+```