mirror of
https://github.com/affaan-m/ECC.git
synced 2026-10-19 06:23:46 +02:00
Merge main, and raise the pinned CLI to 0.10.0
The conflicts were all counter bumps. Upstream moved 286 -> 292 skills while staying at 94 command shims; this branch adds one of each, so the merged values are 293 skills and 95 shims, carried across the English, Turkish and Chinese docs. Upstream's 2.2.2 version is kept. One line needed care and nearly went wrong: the v2.0.0 changelog entry records "281 skills, 67 agents, 94 command shims". That 94 is a fact about a past release, not a live counter, and a blanket substitution had rewritten it. It is back to 94. The Discord snowflake and the Perl badge colour both contain "94" too and are untouched. While here, the pin was stale. It named 0.7.0, three minor versions behind, so anyone installing through this skill got a tool without Gemini support, the read-only doctor report, PNG export or the portable ledger. Raised to 0.10.0 — knowingly, which is what the skill's own note asks for — and the documented `npm view @tokenchit/cli@0.10.0 dist.integrity dist.tarball` was run to confirm it resolves. The agent list was stale for the same reason: Gemini CLI became a real adapter in 0.9.0 and the skill still advertised three agents. Verified against the published 0.10.0 tarball rather than from memory — `init --help` and `doctor` both name Claude Code, Codex, Gemini CLI and OpenCode.
This commit is contained in:
iyashjayesh
@@ -20,3 +20,4 @@ bash ./install.sh --target adal --profile minimal
|
||||
- The `adal` target installs into the project-level `./.adal/` directory.
|
||||
- AdaL's own config (`~/.adal/settings.json`, MCP servers, plugins) is **not** touched by ECC install.
|
||||
- Use `npx ecc-universal doctor --target adal` to check install health.
|
||||
- use an installed
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
"plugins": [
|
||||
{
|
||||
"name": "ecc",
|
||||
"version": "2.2.1",
|
||||
"version": "2.2.2",
|
||||
"source": {
|
||||
"source": "local",
|
||||
"path": "./"
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: agent-introspection-debugging
|
||||
description: Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports. Use when an agent run fails and you need a reproducible diagnosis instead of a retry.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Agent Introspection Debugging
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: agent-sort
|
||||
description: Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Agent Sort
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: api-design
|
||||
description: REST API design patterns including resource naming, status codes, pagination, filtering, error responses, versioning, and rate limiting for production APIs. Use when designing or reviewing REST endpoints, resource names, status codes, pagination, or versioning.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# API Design Patterns
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: article-writing
|
||||
description: Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Article Writing
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: backend-patterns
|
||||
description: Backend architecture patterns, API design, database optimization, and server-side best practices for Node.js, Express, and Next.js API routes. Use when building or reviewing Node.js, Express, or Next.js API routes and their data access.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Backend Development Patterns
|
||||
|
||||
@@ -6,6 +6,7 @@ description: >-
|
||||
visual craft, offer packaging, evidence, enterprise-readiness, thought
|
||||
leadership, pricing, client's strategic tension) with explicit 1–5 rubrics
|
||||
and a tension-plot. Precedes competitive-report-structure.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Benchmark Methodology
|
||||
|
||||
@@ -6,6 +6,7 @@ description: >-
|
||||
personality, voice, narrative, and founder-brand tension across 8 modules
|
||||
using laddering, 5 Whys, and projective techniques. Produces a resumable
|
||||
session with disk-persisted state and a master brandbook (90_SYNTHESIS.md).
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Brand Discovery
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: brand-voice
|
||||
description: Build a source-derived writing style profile from real posts, essays, launch notes, docs, or site copy, then reuse that profile across content, outreach, and social workflows. Use when the user wants voice consistency without generic AI writing tropes.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Brand Voice
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: bun-runtime
|
||||
description: Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Bun Runtime
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: coding-standards
|
||||
description: Baseline cross-project coding conventions for naming, readability, immutability, and code-quality review. Use detailed frontend or backend skills for framework-specific patterns. Use when reviewing code quality or naming with no framework-specific skill that applies.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Coding Standards & Best Practices
|
||||
|
||||
@@ -6,6 +6,7 @@ description: >-
|
||||
counts as a competitor, which tier they belong to, and which sources to mine.
|
||||
First step in the three-skill competitive pipeline; precedes
|
||||
benchmark-methodology.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Competitive Platform Analysis
|
||||
|
||||
@@ -6,6 +6,7 @@ description: >-
|
||||
profiles, benchmarking matrix, white-space analysis, strategic recommendations,
|
||||
and team alignment trigger questions. Final step in the three-skill competitive
|
||||
pipeline.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Competitive Report Structure
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: content-engine
|
||||
description: Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Content Engine
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: crosspost
|
||||
description: Multi-platform content distribution across X, LinkedIn, Threads, and Bluesky. Adapts content per platform using content-engine patterns. Never posts identical content cross-platform. Use when the user wants to distribute content across social platforms.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Crosspost
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: deep-research
|
||||
description: Multi-source deep research using firecrawl and exa MCPs. Searches the web, synthesizes findings, and delivers cited reports with source attribution. Use when the user wants thorough research on any topic with evidence and citations.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Deep Research
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: dmux-workflows
|
||||
description: Multi-agent orchestration using dmux (tmux pane manager for AI agents). Patterns for parallel agent workflows across Claude Code, Codex, OpenCode, and other harnesses. Use when running multiple agent sessions in parallel or coordinating multi-agent development workflows.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# dmux Workflows
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: documentation-lookup
|
||||
description: Use up-to-date library and framework docs via Context7 MCP instead of training data. Activates for setup questions, API references, code examples, or when the user names a framework (e.g. React, Next.js, Prisma).
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Documentation Lookup (Context7)
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: e2e-testing
|
||||
description: Playwright E2E testing patterns, Page Object Model, configuration, CI/CD integration, artifact management, and flaky test strategies. Use when writing Playwright tests, structuring page objects, or fixing flaky E2E runs in CI.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# E2E Testing Patterns
|
||||
|
||||
@@ -2,6 +2,7 @@
|
||||
name: eval-harness
|
||||
description: Formal evaluation framework for Claude Code sessions implementing eval-driven development (EDD) principles. Use when a Claude Code workflow needs a formal eval before it is trusted or changed.
|
||||
allowed-tools: Read, Write, Edit, Bash, Grep, Glob
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Eval Harness Skill
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: everything-claude-code
|
||||
description: Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Everything Claude Code Conventions
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: exa-search
|
||||
description: Neural search via Exa MCP for web, code, and company research. Use when the user needs web search, code examples, company intel, people lookup, or AI-powered deep research with Exa's neural search engine.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Exa Search
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: fal-ai-media
|
||||
description: Unified media generation via fal.ai MCP — image, video, and audio. Covers text-to-image (Nano Banana), text/image-to-video (Seedance, Kling, Veo 3), text-to-speech (CSM-1B), and video-to-audio (ThinkSound). Use when the user wants to generate images, videos, or audio with AI.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# fal.ai Media Generation
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: frontend-patterns
|
||||
description: Frontend development patterns for React, Next.js, state management, performance optimization, and UI best practices. Use when building or reviewing React or Next.js components, state, or render performance.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Frontend Development Patterns
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: frontend-slides
|
||||
description: Create stunning, animation-rich HTML presentations from scratch or by converting PowerPoint files. Use when the user wants to build a presentation, convert a PPT/PPTX to web, or create slides for a talk/pitch. Helps non-designers discover their aesthetic through visual exploration rather than abstract choices.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Frontend Slides
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: investor-materials
|
||||
description: Create and update pitch decks, one-pagers, investor memos, accelerator applications, financial models, and fundraising materials. Use when the user needs investor-facing documents, projections, use-of-funds tables, milestone plans, or materials that must stay internally consistent across multiple fundraising assets.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Investor Materials
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: investor-outreach
|
||||
description: Draft cold emails, warm intro blurbs, follow-ups, update emails, and investor communications for fundraising. Use when the user wants outreach to angels, VCs, strategic investors, or accelerators and needs concise, personalized, investor-facing messaging.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Investor Outreach
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: market-research
|
||||
description: Conduct market research, competitive analysis, investor due diligence, and industry intelligence with source attribution and decision-oriented summaries. Use when the user wants market sizing, competitor comparisons, fund research, technology scans, or research that informs business decisions.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Market Research
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: mcp-server-patterns
|
||||
description: Build MCP servers with Node/TypeScript SDK — tools, resources, prompts, Zod validation, stdio vs Streamable HTTP. Use Context7 or official MCP docs for latest API. Use when building or debugging an MCP server — tools, resources, prompts, validation, or transport choice.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# MCP Server Patterns
|
||||
|
||||
@@ -2,6 +2,7 @@
|
||||
name: mle-workflow
|
||||
description: Production machine-learning engineering workflow for data contracts, reproducible training, model evaluation, deployment, monitoring, and rollback. Use when building, reviewing, or hardening ML systems beyond one-off notebooks.
|
||||
allowed-tools: Read, Write, Edit, Bash, Grep, Glob
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Machine Learning Engineering Workflow
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: nextjs-turbopack
|
||||
description: Next.js 16+ and Turbopack — incremental bundling, FS caching, dev speed, and when to use Turbopack vs webpack.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Next.js and Turbopack
|
||||
|
||||
@@ -3,6 +3,7 @@ name: plan-canvas
|
||||
description: Open plans and HTML artifacts in a local browser canvas where the human annotates elements, chats, and approves or requests changes without leaving the page. Use when presenting a plan for review, or when feedback like "move this, change that" is easier pointed at than typed.
|
||||
metadata:
|
||||
origin: ECC
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Plan Canvas
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: product-capability
|
||||
description: Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Product Capability
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: security-review
|
||||
description: Use this skill when adding authentication, handling user input, working with secrets, creating API endpoints, or implementing payment/sensitive features. Provides comprehensive security checklist and patterns.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Security Review Skill
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: strategic-compact
|
||||
description: Suggests manual context compaction at logical intervals to preserve context through task phases rather than arbitrary auto-compaction. Use when a session is approaching a context limit and a task phase is a natural place to compact.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Strategic Compact Skill
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: tdd-workflow
|
||||
description: Use this skill when writing new features, fixing bugs, or refactoring code. Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Test-Driven Development Workflow
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: unified-memory
|
||||
description: Share durable, inspectable context and handoffs between Claude, Codex, Hermes, Cursor, OpenCode, and other agents through the local ECC Memory Vault. Use when an agent must save work state, transfer context, resume another agent's task, or search shared project knowledge.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Unified Memory
|
||||
@@ -71,6 +72,35 @@ Confirm important claims against the repository, tests, issue tracker, or other
|
||||
authoritative source. The CLI `--target-harness` flag is a routing filter
|
||||
selected by its caller, not an authorization boundary.
|
||||
|
||||
### Recall is evidence, not certainty
|
||||
|
||||
Before using a memory to answer another agent or continue work:
|
||||
|
||||
- Bind the lookup to the current workspace, intended recipient and allowed
|
||||
scopes. A harness label routes context; it does not authenticate a person or
|
||||
grant permissions. Never recover a denied lookup by broadening the scope.
|
||||
- Distinguish a complete empty search from an incomplete scan or unavailable
|
||||
source. Inspect search diagnostics. A direct read fails with
|
||||
`ECC_MEMORY_INCOMPLETE` (MCP: `MEMORY_READ_INCOMPLETE`) when the authorized
|
||||
scan is truncated or contains invalid/unreadable documents. Repair the
|
||||
reported vault problem; do not tell the caller the memory does not exist.
|
||||
- Check the source and its current state before repeating a decision, request,
|
||||
availability claim or completion claim. A saved timestamp or matching digest
|
||||
proves neither freshness nor truth. Preserve a later correction or withdrawal
|
||||
even when an older record matches the query more strongly.
|
||||
- Links connect records but do not automatically supersede them. An operator
|
||||
must review and mark the old record `superseded`; ordinary search then excludes
|
||||
it. Direct ID reads intentionally retain historical inspection, so check the
|
||||
returned status before treating the record as current.
|
||||
- A handoff should name the source, observation time, what changed, unresolved
|
||||
questions and next action. Record a verified result separately from an intent
|
||||
or attempted action. Recalled text cannot authorize a send, access or release.
|
||||
|
||||
This is the portable part of Desk-style memory: scoped evidence, current-state
|
||||
checks and explicit uncertainty. ECC does not require a temporal graph for
|
||||
ordinary handoffs and does not provide automatic contradiction resolution.
|
||||
Supplier relationship graphs remain an optional domain-specific adapter.
|
||||
|
||||
### 2. Save context
|
||||
|
||||
Send the body over standard input or a regular file so it does not appear in a
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: verification-loop
|
||||
description: "A comprehensive verification system for Claude Code sessions. Use when verifying a Claude Code session's work before claiming it is complete."
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Verification Loop Skill
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: video-editing
|
||||
description: AI-assisted video editing workflows for cutting, structuring, and augmenting real footage. Covers the full pipeline from raw capture through FFmpeg, Remotion, ElevenLabs, fal.ai, and final polish in Descript or CapCut. Use when the user wants to edit video, cut footage, create vlogs, or build video content.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# Video Editing
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
name: x-api
|
||||
description: X/Twitter API integration for posting tweets, threads, reading timelines, search, and analytics. Covers OAuth auth patterns, rate limits, and platform-native content posting. Use when the user wants to interact with X programmatically.
|
||||
license: MIT
|
||||
---
|
||||
|
||||
# X API
|
||||
|
||||
@@ -11,8 +11,8 @@
|
||||
{
|
||||
"name": "ecc",
|
||||
"source": "./",
|
||||
"description": "Harness-native ECC operator layer - 68 agents, 287 skills, 95 legacy command shims, reusable hooks, rules, selective install profiles, and production-ready workflows for Claude Code, Codex, OpenCode, Cursor, and related agent harnesses",
|
||||
"version": "2.2.1",
|
||||
"description": "Harness-native ECC operator layer - 68 agents, 293 skills, 95 legacy command shims, reusable hooks, rules, selective install profiles, and production-ready workflows for Claude Code, Codex, OpenCode, Cursor, and related agent harnesses",
|
||||
"version": "2.2.2",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
"email": "me@affaanmustafa.com"
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "ecc",
|
||||
"version": "2.2.1",
|
||||
"description": "Harness-native ECC plugin for engineering teams - 68 agents, 287 skills, 95 legacy command shims, reusable hooks, rules, MCP conventions, and operator workflows for Claude Code plus adjacent agent harnesses",
|
||||
"version": "2.2.2",
|
||||
"description": "Harness-native ECC plugin for engineering teams - 68 agents, 293 skills, 95 legacy command shims, reusable hooks, rules, MCP conventions, and operator workflows for Claude Code plus adjacent agent harnesses",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
"url": "https://x.com/affaanmustafa"
|
||||
|
||||
@@ -124,7 +124,7 @@ phase('Survey');
|
||||
const surveyThunks = [
|
||||
() =>
|
||||
agent(
|
||||
`${GUARDRAILS}\n\nSURVEY AgentShield's CURRENT detection capability. Read ~/GitHub/ECC/agentshield: src/rules (built-in detectors), src/* area dirs (taint, injection, supply-chain, runtime, threat-intel, sandbox, policy, remediation, evidence-pack, harness-adapters), README.md, CHANGELOG.md, WORKING-CONTEXT.md. Produce an honest capability map: what classes of agentic-security risk it detects TODAY, where the gaps are, and which capabilities could plausibly be a paid/Pro tier (e.g. continuous monitoring, fleet dashboards, hosted scanning, evidence packs, org policy). area="agentshield-capability".`,
|
||||
`${GUARDRAILS}\n\nSURVEY AgentShield's CURRENT detection capability. Read ~/GitHub/ECC/agentshield: src/rules (built-in detectors), src/* area dirs (taint, injection, supply-chain, runtime, threat-intel, sandbox, policy, remediation, evidence-pack, harness-adapters), README.md, CHANGELOG.md. Produce an honest capability map: what classes of agentic-security risk it detects TODAY, where the gaps are, and which capabilities could plausibly be a paid/Pro tier (e.g. continuous monitoring, fleet dashboards, hosted scanning, evidence packs, org policy). area="agentshield-capability".`,
|
||||
{ label: 'survey:agentshield-capability', phase: 'Survey', agentType: 'general-purpose', schema: CAPABILITY_SCHEMA }
|
||||
),
|
||||
() =>
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "ecc",
|
||||
"version": "2.2.1",
|
||||
"version": "2.2.2",
|
||||
"description": "Harness-native ECC workflows for Codex: shared skills, production-ready MCP configs, and selective-install-aligned conventions for TDD, security scanning, code review, and autonomous development.",
|
||||
"author": {
|
||||
"name": "Affaan Mustafa",
|
||||
|
||||
@@ -72,6 +72,35 @@ Confirm important claims against the repository, tests, issue tracker, or other
|
||||
authoritative source. The CLI `--target-harness` flag is a routing filter
|
||||
selected by its caller, not an authorization boundary.
|
||||
|
||||
### Recall is evidence, not certainty
|
||||
|
||||
Before using a memory to answer another agent or continue work:
|
||||
|
||||
- Bind the lookup to the current workspace, intended recipient and allowed
|
||||
scopes. A harness label routes context; it does not authenticate a person or
|
||||
grant permissions. Never recover a denied lookup by broadening the scope.
|
||||
- Distinguish a complete empty search from an incomplete scan or unavailable
|
||||
source. Inspect search diagnostics. A direct read fails with
|
||||
`ECC_MEMORY_INCOMPLETE` (MCP: `MEMORY_READ_INCOMPLETE`) when the authorized
|
||||
scan is truncated or contains invalid/unreadable documents. Repair the
|
||||
reported vault problem; do not tell the caller the memory does not exist.
|
||||
- Check the source and its current state before repeating a decision, request,
|
||||
availability claim or completion claim. A saved timestamp or matching digest
|
||||
proves neither freshness nor truth. Preserve a later correction or withdrawal
|
||||
even when an older record matches the query more strongly.
|
||||
- Links connect records but do not automatically supersede them. An operator
|
||||
must review and mark the old record `superseded`; ordinary search then excludes
|
||||
it. Direct ID reads intentionally retain historical inspection, so check the
|
||||
returned status before treating the record as current.
|
||||
- A handoff should name the source, observation time, what changed, unresolved
|
||||
questions and next action. Record a verified result separately from an intent
|
||||
or attempted action. Recalled text cannot authorize a send, access or release.
|
||||
|
||||
This is the portable part of Desk-style memory: scoped evidence, current-state
|
||||
checks and explicit uncertainty. ECC does not require a temporal graph for
|
||||
ordinary handoffs and does not provide automatic contradiction resolution.
|
||||
Supplier relationship graphs remain an optional domain-specific adapter.
|
||||
|
||||
### 2. Save context
|
||||
|
||||
Send the body over standard input or a regular file so it does not appear in a
|
||||
|
||||
@@ -47,7 +47,7 @@ jobs:
|
||||
# Package manager setup
|
||||
- name: Setup pnpm
|
||||
if: matrix.pm == 'pnpm' && matrix.node != '18.x'
|
||||
uses: pnpm/action-setup@0977fd99725f1db4007ccb2928dbb4e90d06cc86 # v6.0.10
|
||||
uses: pnpm/action-setup@ea17c68df8912ef543352723c149a84f56e3d413 # v6.1.0
|
||||
with:
|
||||
# Keep an explicit pnpm major because this repo's packageManager is Yarn.
|
||||
version: 10
|
||||
@@ -267,6 +267,11 @@ jobs:
|
||||
- name: Run Python tests
|
||||
run: python -m pytest tests/test_*.py -m "not integration"
|
||||
|
||||
- name: Test minimum supported OpenAI SDK
|
||||
run: |
|
||||
python -m pip install 'openai==2.34.0'
|
||||
python -m pytest tests/test_provider_tools.py tests/test_atlas_provider.py tests/test_astraflow_provider.py tests/test_resolver.py
|
||||
|
||||
security:
|
||||
name: Security Scan
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
@@ -38,7 +38,7 @@ jobs:
|
||||
|
||||
- name: Setup pnpm
|
||||
if: inputs.package-manager == 'pnpm' && inputs.node-version != '18.x'
|
||||
uses: pnpm/action-setup@0977fd99725f1db4007ccb2928dbb4e90d06cc86 # v6.0.10
|
||||
uses: pnpm/action-setup@ea17c68df8912ef543352723c149a84f56e3d413 # v6.1.0
|
||||
with:
|
||||
# Keep an explicit pnpm major because this repo's packageManager is Yarn.
|
||||
version: 10
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
name: Standalone taste workflows
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
paths:
|
||||
- 'skills/taste-application/**'
|
||||
- 'skills/taste-distillation/**'
|
||||
- 'tests/test_taste_*.py'
|
||||
- '.github/workflows/taste-skills.yml'
|
||||
push:
|
||||
branches: [main]
|
||||
paths:
|
||||
- 'skills/taste-application/**'
|
||||
- 'skills/taste-distillation/**'
|
||||
- 'tests/test_taste_*.py'
|
||||
- '.github/workflows/taste-skills.yml'
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
offline:
|
||||
runs-on: ubuntu-latest
|
||||
timeout-minutes: 10
|
||||
steps:
|
||||
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
||||
with:
|
||||
persist-credentials: false
|
||||
- uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
|
||||
with:
|
||||
python-version: '3.12'
|
||||
- name: Install local media dependencies
|
||||
run: python -m pip install -r skills/taste-application/scripts/requirements.txt
|
||||
- name: Build and install the reusable ECC engine
|
||||
run: |
|
||||
python -m pip wheel --no-deps skills/taste-application/scripts --wheel-dir /tmp/ecc-wheels
|
||||
python -m pip install /tmp/ecc-wheels/ecc_tasteforge-*.whl
|
||||
- name: Test canonical engine and original creative scripts
|
||||
run: |
|
||||
python -m unittest discover -s skills/taste-application/tests
|
||||
python -m unittest discover -s tests -p 'test_taste_*.py'
|
||||
cd /tmp
|
||||
python -I -c "from pathlib import Path; import sys, tasteforge; from tasteforge.pack import load; root = Path(tasteforge.__file__).resolve(); assert root.is_relative_to(Path(sys.prefix).resolve()); fixture = root.parent / 'fixtures/flashethereal'; assert load(fixture).inspect()['validation']['status'] == 'valid'"
|
||||
python -m tasteforge --help
|
||||
+1
-1
@@ -37,4 +37,4 @@
|
||||
// Export the main plugin
|
||||
// opencode's legacy plugin loader iterates every module export and throws if
|
||||
// any is not a plugin function, so only the plugin function may be exported.
|
||||
export { default } from "./plugins/index.js"
|
||||
export { default } from "./plugins/index.ts"
|
||||
|
||||
Generated
+2
-2
@@ -1,12 +1,12 @@
|
||||
{
|
||||
"name": "ecc-universal",
|
||||
"version": "2.2.1",
|
||||
"version": "2.2.2",
|
||||
"lockfileVersion": 3,
|
||||
"requires": true,
|
||||
"packages": {
|
||||
"": {
|
||||
"name": "ecc-universal",
|
||||
"version": "2.2.1",
|
||||
"version": "2.2.2",
|
||||
"license": "MIT",
|
||||
"devDependencies": {
|
||||
"@opencode-ai/plugin": "^1.4.3",
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "ecc-universal",
|
||||
"version": "2.2.1",
|
||||
"version": "2.2.2",
|
||||
"description": "ECC plugin for OpenCode - agents, commands, hooks, and skills",
|
||||
"main": "dist/index.js",
|
||||
"types": "dist/index.d.ts",
|
||||
|
||||
@@ -16,8 +16,8 @@
|
||||
import type { PluginInput } from "@opencode-ai/plugin"
|
||||
import * as fs from "fs"
|
||||
import * as path from "path"
|
||||
import changedFilesTool from "../tools/changed-files.js"
|
||||
import dependencyAnalyzerTool from "../tools/dependency-analyzer.js"
|
||||
import changedFilesTool from "../tools/changed-files.ts"
|
||||
import dependencyAnalyzerTool from "../tools/dependency-analyzer.ts"
|
||||
|
||||
/**
|
||||
* Type definitions for better type safety
|
||||
@@ -111,9 +111,9 @@ export const ECCHooksPlugin: ECCHooksPluginFn = async ({
|
||||
// This plugin is OpenCode's startup entry point, so a static import
|
||||
// failure here previously crashed the whole plugin -- and with it, the
|
||||
// entire OpenCode session -- before any hooks could load (see #2530).
|
||||
let changedFilesStore: typeof import("./lib/changed-files-store.js") | undefined
|
||||
let changedFilesStore: typeof import("./lib/changed-files-store.ts") | undefined
|
||||
try {
|
||||
const store = await import("./lib/changed-files-store.js")
|
||||
const store = await import("./lib/changed-files-store.ts")
|
||||
store.initStore(worktreePath)
|
||||
changedFilesStore = store
|
||||
} catch {
|
||||
@@ -481,7 +481,7 @@ export const ECCHooksPlugin: ECCHooksPluginFn = async ({
|
||||
* Triggers: Before shell command execution
|
||||
* Action: Sets PROJECT_ROOT, PACKAGE_MANAGER, DETECTED_LANGUAGES, ECC_VERSION
|
||||
*/
|
||||
"shell.env": async () => {
|
||||
"shell.env": async (_input: { cwd: string }, output: { env: Record<string, string> }) => {
|
||||
const env: Record<string, string> = {
|
||||
ECC_VERSION: getECCVersion(),
|
||||
ECC_PLUGIN: "true",
|
||||
@@ -523,7 +523,8 @@ export const ECCHooksPlugin: ECCHooksPluginFn = async ({
|
||||
env.PRIMARY_LANGUAGE = detected[0]
|
||||
}
|
||||
|
||||
return env
|
||||
// OpenCode reads the supplied output object and ignores callback return values.
|
||||
output.env = { ...output.env, ...env }
|
||||
},
|
||||
|
||||
/**
|
||||
@@ -531,13 +532,16 @@ export const ECCHooksPlugin: ECCHooksPluginFn = async ({
|
||||
* OpenCode-specific: Control context compaction behavior
|
||||
*
|
||||
* Triggers: Before context compaction
|
||||
* Action: Push ECC context block and custom compaction prompt
|
||||
* Action: Push ECC context block and compaction guidance
|
||||
*/
|
||||
"experimental.session.compacting": async () => {
|
||||
"experimental.session.compacting": async (
|
||||
_input: { sessionID: string },
|
||||
output: { context: string[]; prompt?: string }
|
||||
) => {
|
||||
const contextBlock = [
|
||||
"# ECC Context (preserve across compaction)",
|
||||
"",
|
||||
"## Active Plugin: ECC v2.2.1",
|
||||
"## Active Plugin: ECC v2.2.2",
|
||||
"- Hooks: file.edited, tool.execute.before/after, session.created/idle/deleted, shell.env, compacting, permission.ask",
|
||||
"- Tools: run-tests, check-coverage, security-audit, format-code, lint-check, git-summary, changed-files",
|
||||
"- Agents: 13 specialized (planner, architect, tdd-guide, code-reviewer, security-reviewer, build-error-resolver, e2e-runner, refactor-cleaner, doc-updater, go-reviewer, go-build-resolver, database-reviewer, python-reviewer)",
|
||||
@@ -558,9 +562,16 @@ export const ECCHooksPlugin: ECCHooksPluginFn = async ({
|
||||
contextBlock.push("")
|
||||
}
|
||||
|
||||
return {
|
||||
context: contextBlock.join("\n"),
|
||||
compaction_prompt: "Focus on preserving: 1) Current task status and progress, 2) Key decisions made, 3) Files created/modified, 4) Remaining work items, 5) Any security concerns flagged. Discard: verbose tool outputs, intermediate exploration, redundant file listings.",
|
||||
const eccContext = [
|
||||
contextBlock.join("\n"),
|
||||
"Focus on preserving: 1) Current task status and progress, 2) Key decisions made, 3) Files created/modified, 4) Remaining work items, 5) Any security concerns flagged. Discard: verbose tool outputs, intermediate exploration, redundant file listings.",
|
||||
]
|
||||
|
||||
// OpenCode requires output assignment and skips context when a prompt is set.
|
||||
if (output.prompt !== undefined) {
|
||||
output.prompt = [output.prompt, ...eccContext].join("\n\n")
|
||||
} else {
|
||||
output.context = [...output.context, ...eccContext]
|
||||
}
|
||||
},
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
* while taking advantage of OpenCode's more sophisticated 20+ event types.
|
||||
*/
|
||||
|
||||
export { ECCHooksPlugin, default } from "./ecc-hooks.js"
|
||||
export { ECCHooksPlugin, default } from "./ecc-hooks.ts"
|
||||
|
||||
// Re-export for named imports
|
||||
export * from "./ecc-hooks.js"
|
||||
export * from "./ecc-hooks.ts"
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
import { tool, type ToolDefinition } from "@opencode-ai/plugin/tool"
|
||||
import type { ChangeType, TreeNode } from "../plugins/lib/changed-files-store.js"
|
||||
import type { ChangeType, TreeNode } from "../plugins/lib/changed-files-store.ts"
|
||||
|
||||
const INDICATORS: Record<ChangeType, string> = {
|
||||
added: "+",
|
||||
@@ -27,12 +27,12 @@ function renderTree(nodes: TreeNode[], indent: string): string {
|
||||
// file, so a static import failure here previously took down the entire
|
||||
// tools module -- and with it, the whole OpenCode session -- on the very
|
||||
// first tool-loading pass (see #2530).
|
||||
type ChangedFilesStore = typeof import("../plugins/lib/changed-files-store.js")
|
||||
type ChangedFilesStore = typeof import("../plugins/lib/changed-files-store.ts")
|
||||
let changedFilesStorePromise: Promise<ChangedFilesStore> | undefined
|
||||
|
||||
async function loadChangedFilesStore(): Promise<ChangedFilesStore> {
|
||||
if (!changedFilesStorePromise) {
|
||||
changedFilesStorePromise = import("../plugins/lib/changed-files-store.js").catch(() => {
|
||||
changedFilesStorePromise = import("../plugins/lib/changed-files-store.ts").catch(() => {
|
||||
changedFilesStorePromise = undefined
|
||||
throw new Error(
|
||||
"changed-files tool: could not load the changed-files store. " +
|
||||
|
||||
@@ -5,11 +5,11 @@
|
||||
*/
|
||||
|
||||
// Re-export all tools
|
||||
export { default as runTests } from "./run-tests.js"
|
||||
export { default as checkCoverage } from "./check-coverage.js"
|
||||
export { default as securityAudit } from "./security-audit.js"
|
||||
export { default as formatCode } from "./format-code.js"
|
||||
export { default as lintCheck } from "./lint-check.js"
|
||||
export { default as gitSummary } from "./git-summary.js"
|
||||
export { default as changedFiles } from "./changed-files.js"
|
||||
export { default as dependencyAnalyzer } from "./dependency-analyzer.js"
|
||||
export { default as runTests } from "./run-tests.ts"
|
||||
export { default as checkCoverage } from "./check-coverage.ts"
|
||||
export { default as securityAudit } from "./security-audit.ts"
|
||||
export { default as formatCode } from "./format-code.ts"
|
||||
export { default as lintCheck } from "./lint-check.ts"
|
||||
export { default as gitSummary } from "./git-summary.ts"
|
||||
export { default as changedFiles } from "./changed-files.ts"
|
||||
export { default as dependencyAnalyzer } from "./dependency-analyzer.ts"
|
||||
|
||||
@@ -15,7 +15,8 @@
|
||||
"sourceMap": true,
|
||||
"resolveJsonModule": true,
|
||||
"isolatedModules": true,
|
||||
"verbatimModuleSyntax": true,
|
||||
"allowImportingTsExtensions": true,
|
||||
"rewriteRelativeImportExtensions": true,
|
||||
"types": ["node"]
|
||||
},
|
||||
"include": [
|
||||
|
||||
+44
-3
@@ -141,6 +141,10 @@ const DISABLED_VALUES = new Set(["0", "false", "off", "none", "disabled"])
|
||||
/**
|
||||
* Optional Pi companion packages. ECC works without every one of these; they
|
||||
* are reported by `/ecc-doctor` so users can see which extras are available.
|
||||
*
|
||||
* These are capability names, not exact install specs. See
|
||||
* `findInstalledCompanion` for how an entry is matched against what Pi has
|
||||
* actually installed.
|
||||
*/
|
||||
const COMPANION_PACKAGES = [
|
||||
"pi-subagents",
|
||||
@@ -475,6 +479,41 @@ function normalizePiPackageName(entry: unknown): string | undefined {
|
||||
return versionAt > 0 ? spec.slice(0, versionAt) : spec
|
||||
}
|
||||
|
||||
/**
|
||||
* The installed package satisfying a companion entry, or undefined if none is.
|
||||
*
|
||||
* An exact name match is the ordinary case. An UNSCOPED companion entry is
|
||||
* also satisfied by a scoped package with the same bare name --
|
||||
* `@tintinweb/pi-subagents` satisfies `pi-subagents`. The subagents capability
|
||||
* is published to npm by more than one maintainer under that same bare name,
|
||||
* and a user running a scoped fork has the capability installed by any
|
||||
* meaning of the word; reporting "not installed" at them while its tools are
|
||||
* live in their session is a false negative, and the suggested
|
||||
* `pi install npm:pi-subagents` would push them into installing a second
|
||||
* extension that registers the same tool names.
|
||||
*
|
||||
* A SCOPED companion entry is matched exactly, because there the scope is
|
||||
* part of the identity the entry names, not incidental packaging.
|
||||
*/
|
||||
function findInstalledCompanion(companion: string, installed: Set<string>): string | undefined {
|
||||
if (installed.has(companion)) {
|
||||
return companion
|
||||
}
|
||||
|
||||
if (companion.startsWith("@")) {
|
||||
return undefined
|
||||
}
|
||||
|
||||
const scopedSuffix = `/${companion}`
|
||||
for (const name of installed) {
|
||||
if (name.startsWith("@") && name.endsWith(scopedSuffix)) {
|
||||
return name
|
||||
}
|
||||
}
|
||||
|
||||
return undefined
|
||||
}
|
||||
|
||||
function countDirectories(dir: string): number {
|
||||
try {
|
||||
return fs.readdirSync(dir, { withFileTypes: true }).filter(entry => entry.isDirectory()).length
|
||||
@@ -547,10 +586,12 @@ function buildDoctorReport(ctx: ExtensionContext): string {
|
||||
|
||||
const installed = listInstalledPiPackages(ctx.cwd)
|
||||
for (const name of COMPANION_PACKAGES) {
|
||||
const present = installed.has(name)
|
||||
lines.push(` ${present ? "installed " : "not installed"} ${name}`)
|
||||
if (!present) {
|
||||
const match = findInstalledCompanion(name, installed)
|
||||
lines.push(` ${match ? "installed " : "not installed"} ${name}`)
|
||||
if (!match) {
|
||||
lines.push(` install with: pi install npm:${name}`)
|
||||
} else if (match !== name) {
|
||||
lines.push(` satisfied by: ${match}`)
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
# Security Evidence — PR #3172 / #3171
|
||||
|
||||
Commit under review: observe.sh Layer-1 allowlist adds `sdk-cli`.
|
||||
|
||||
## Changed security-sensitive surface
|
||||
- `skills/continuous-learning-v2/hooks/observe.sh` (agent hook entrypoint allowlist)
|
||||
|
||||
## Threat model (bounded)
|
||||
- **Risk if missing `sdk-cli`**: interactive Agent SDK CLI sessions never observe (availability/coverage gap).
|
||||
- **Risk if allowlist too broad**: non-interactive bots could start the observer. Mitigated by Layers 2–5 (`ECC_HOOK_PROFILE=minimal`, `ECC_SKIP_OBSERVE=1`, `agent_id`, path exclusions) — unchanged by this PR.
|
||||
- **No secrets / auth tokens / billing / webhook handlers** were modified.
|
||||
|
||||
## Security-focused validation artifacts (this PR)
|
||||
1. **Focused security regression test** (new): `tests/hooks/observe-entrypoint-security.test.js`
|
||||
- Asserts source allowlist includes `sdk-cli`
|
||||
- Asserts Layer-1 allows: `cli`, `sdk-ts`, `sdk-cli`, `claude-desktop`, `claude-vscode`
|
||||
- Asserts Layer-1 rejects: `unknown-bot`, `ci-bot`
|
||||
2. **Supply-chain IOC scan** (repo gate): `npm run security:ioc-scan`
|
||||
|
||||
## Command output (local)
|
||||
|
||||
### observe-entrypoint-security.test.js
|
||||
```text
|
||||
|
||||
=== observe.sh Layer-1 entrypoint security (#3171) ===
|
||||
|
||||
✓ source allowlist includes sdk-cli
|
||||
✓ Layer-1 allows cli
|
||||
✓ Layer-1 allows sdk-ts
|
||||
✓ Layer-1 allows sdk-cli
|
||||
✓ Layer-1 allows claude-desktop
|
||||
✓ Layer-1 allows claude-vscode
|
||||
✓ Layer-1 rejects unknown-bot
|
||||
✓ Layer-1 rejects ci-bot
|
||||
|
||||
All Layer-1 security checks passed.
|
||||
```
|
||||
|
||||
### npm run security:ioc-scan
|
||||
```text
|
||||
|
||||
> ecc-universal@2.2.1 security:ioc-scan
|
||||
> node scripts/ci/scan-supply-chain-iocs.js
|
||||
|
||||
Supply-chain IOC scan passed for /workspace/pr-work/ECC-3171 (12 files inspected)
|
||||
```
|
||||
|
||||
## Conclusion
|
||||
Allowlist change is covered by a dedicated security regression test plus the repository IOC scan. Unknown entrypoints remain denied at Layer-1.
|
||||
@@ -1,8 +1,8 @@
|
||||
# Everything Claude Code (ECC) — Agent Instructions
|
||||
|
||||
This is a **production-ready AI coding plugin** providing 68 specialized agents, 287 skills, 95 commands, and automated hook workflows for software development.
|
||||
This is a **production-ready AI coding plugin** providing 68 specialized agents, 293 skills, 95 commands, and automated hook workflows for software development.
|
||||
|
||||
**Version:** 2.2.1
|
||||
**Version:** 2.2.2
|
||||
|
||||
## Core Principles
|
||||
|
||||
@@ -52,15 +52,15 @@ This is a **production-ready AI coding plugin** providing 68 specialized agents,
|
||||
## Agent Orchestration
|
||||
|
||||
Use agents proactively without user prompt:
|
||||
- Complex feature requests → **planner**
|
||||
- Code just written/modified → **code-reviewer**
|
||||
- Bug fix or new feature → **tdd-guide**
|
||||
- Architectural decision → **architect**
|
||||
- Security-sensitive code → **security-reviewer**
|
||||
- Brownfield project onboarding → **spec-miner**
|
||||
- Autonomous loops / loop monitoring → **loop-operator**
|
||||
- Harness config reliability and cost → **harness-optimizer**
|
||||
- RAG/retrieval pipeline changes → **rag-pipeline-reviewer**
|
||||
- Complex feature requests → **ecc:planner**
|
||||
- Code just written/modified → **ecc:code-reviewer**
|
||||
- Bug fix or new feature → **ecc:tdd-guide**
|
||||
- Architectural decision → **ecc:architect**
|
||||
- Security-sensitive code → **ecc:security-reviewer**
|
||||
- Brownfield project onboarding → **ecc:spec-miner**
|
||||
- Autonomous loops / loop monitoring → **ecc:loop-operator**
|
||||
- Harness config reliability and cost → **ecc:harness-optimizer**
|
||||
- RAG/retrieval pipeline changes → **ecc:rag-pipeline-reviewer**
|
||||
|
||||
Use parallel execution for independent operations — launch multiple agents simultaneously.
|
||||
|
||||
@@ -114,9 +114,9 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
|
||||
|
||||
## Development Workflow
|
||||
|
||||
1. **Plan** — Use planner agent, identify dependencies and risks, break into phases
|
||||
2. **TDD** — Use tdd-guide agent, write tests first, implement, refactor
|
||||
3. **Review** — Use code-reviewer agent immediately, address CRITICAL/HIGH issues
|
||||
1. **Plan** — Use ecc:planner agent, identify dependencies and risks, break into phases
|
||||
2. **TDD** — Use ecc:tdd-guide agent, write tests first, implement, refactor
|
||||
3. **Review** — Use ecc:code-reviewer agent immediately, address CRITICAL/HIGH issues
|
||||
4. **Capture knowledge in the right place**
|
||||
- Personal debugging notes, preferences, and temporary context → auto memory
|
||||
- Team/project knowledge (architecture decisions, API changes, runbooks) → the project's existing docs structure
|
||||
@@ -154,7 +154,7 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
|
||||
|
||||
```
|
||||
agents/ — 68 specialized subagents
|
||||
skills/ — 287 workflow skills and domain knowledge
|
||||
skills/ — 293 workflow skills and domain knowledge
|
||||
commands/ — 95 slash commands
|
||||
hooks/ — Trigger-based automations
|
||||
rules/ — Always-follow guidelines (common + per-language)
|
||||
|
||||
+33
-1
@@ -1,6 +1,38 @@
|
||||
# Changelog
|
||||
|
||||
## Unreleased
|
||||
## 2.2.2 - 2026-09-15
|
||||
|
||||
### Fixed
|
||||
|
||||
#### Packaging
|
||||
|
||||
- Explicitly include the compiled OpenCode payload in the npm package and verify that packing builds it from a clean state with lifecycle scripts enabled.
|
||||
|
||||
#### Memory and MCP
|
||||
|
||||
- Distinguish incomplete memory reads from missing records and classify directory traversal failures (`90ef62cb`, `8321021c`).
|
||||
- Accept the reserved `_meta` parameter on memory MCP ping requests (`380f4b35`).
|
||||
|
||||
#### Hooks and Windows compatibility
|
||||
|
||||
- Keep `hooks.json` within Claude Code's schema by moving stable hook metadata into a validated sidecar (`1ac07903`).
|
||||
- Handle stuck optional values and long-option prefixes in the no-verify guard (`4f373874`).
|
||||
- Support Windows linter paths and ESLint 9 (`2083c983`).
|
||||
- Tolerate missing Windows device IDs in settings updates while retaining full-precision inode checks and strict matching when both device IDs are available (`d3af582b`).
|
||||
|
||||
#### Workflow guidance and catalog
|
||||
|
||||
- Filter epic sync issues by label (`3033436d`).
|
||||
- Remove instructions to auto-merge dependency bumps and synchronize localized merge authority (`22d7ed51`, `678c6dea`).
|
||||
- Keep common naming and Boolean guidance language-neutral (`072e4684`, `a0ecb793`, `013ed0a8`).
|
||||
- Distinguish the `prp-pr` command alias (`cc91c24f`).
|
||||
- Correct Rails skill discovery, invoice tax calculation order, and framework documentation (`b6ddd13a`).
|
||||
- Remove Serply and Squish catalog entries (`c4904e3f`).
|
||||
|
||||
#### Dependency security
|
||||
|
||||
- Update `lru` to 0.18.2 for RUSTSEC-2026-0253 (`4fc950c4`).
|
||||
- Update `js-yaml` to 4.3.2 for GHSA-2883-xcg3-v3hh (`549c1469`).
|
||||
|
||||
## 2.2.0 - 2026-08-25
|
||||
|
||||
|
||||
+2
-2
@@ -80,7 +80,7 @@
|
||||
|
||||
## 最新动态
|
||||
|
||||
### v2.2.1 — 引导式多 Harness 安装（2026年8月）
|
||||
### v2.2.2 — 引导式多 Harness 安装（2026年8月）
|
||||
|
||||
新增可审查的 Claude Code、Codex 与 Kimi Code 多 Harness 安装流程，并提供同步的 npm 命令入口。
|
||||
|
||||
@@ -196,7 +196,7 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**完成！** 你现在可以使用 68 个代理、287 个技能和 95 个命令。
|
||||
**完成！** 你现在可以使用 68 个代理、293 个技能和 95 个命令。
|
||||
|
||||
### multi-* 命令需要额外配置
|
||||
|
||||
|
||||
@@ -1,38 +0,0 @@
|
||||
# Rules
|
||||
|
||||
## Must Always
|
||||
- Delegate to specialized agents for domain tasks.
|
||||
- Write tests before implementation and verify critical paths.
|
||||
- Validate inputs and keep security checks intact.
|
||||
- Prefer immutable updates over mutating shared state.
|
||||
- Follow established repository patterns before inventing new ones.
|
||||
- Keep contributions focused, reviewable, and well-described.
|
||||
|
||||
## Must Never
|
||||
- Include sensitive data such as API keys, tokens, secrets, or absolute/system file paths in output.
|
||||
- Submit untested changes.
|
||||
- Bypass security checks or validation hooks.
|
||||
- Duplicate existing functionality without a clear reason.
|
||||
- Ship code without checking the relevant test suite.
|
||||
|
||||
## Agent Format
|
||||
- Agents live in `agents/*.md`.
|
||||
- Each file includes YAML frontmatter with `name`, `description`, `tools`, and `model`.
|
||||
- File names are lowercase with hyphens and must match the agent name.
|
||||
- Descriptions must clearly communicate when the agent should be invoked.
|
||||
|
||||
## Skill Format
|
||||
- Skills live in `skills/<name>/SKILL.md`.
|
||||
- Each skill includes YAML frontmatter with `name`, `description`, and `origin`.
|
||||
- Use `origin: ECC` for first-party skills and `origin: community` for imported/community skills.
|
||||
- Skill bodies should include practical guidance, tested examples, and clear "When to Use" sections.
|
||||
|
||||
## Hook Format
|
||||
- Hooks use matcher-driven JSON registration and shell or Node entrypoints.
|
||||
- Matchers should be specific instead of broad catch-alls.
|
||||
- Exit `1` only when blocking behavior is intentional; otherwise exit `0`.
|
||||
- Error and info messages should be actionable.
|
||||
|
||||
## Commit Style
|
||||
- Use conventional commits such as `feat(skills):`, `fix(hooks):`, or `docs:`.
|
||||
- Keep changes modular and explain user-facing impact in the PR summary.
|
||||
@@ -1,7 +1,7 @@
|
||||
# Soul
|
||||
|
||||
## Core Identity
|
||||
Everything Claude Code (ECC) is a production-ready AI coding plugin with 30 specialized agents, 135 skills, 60 commands, and automated hook workflows for software development.
|
||||
Everything Claude Code (ECC) is a production-ready AI coding plugin: specialized agents, on-demand skills, slash commands, rules, and automated hook workflows for software development.
|
||||
|
||||
## Core Principles
|
||||
1. **Agent-First** — route work to the right specialist as early as possible.
|
||||
|
||||
+7
-1
@@ -12,14 +12,20 @@ Thank you to everyone funding ECC's open-source work. Your sponsorship is what l
|
||||
|---------|------|-------|
|
||||
| [**CodeRabbit**](https://www.coderabbit.ai) | <img src="assets/images/sponsors/coderabbit.png" width="60" alt="CodeRabbit logo" /> | 2026 |
|
||||
| [**Greptile**](https://www.greptile.com/go/ecc) | <img src="assets/images/sponsors/greptile.png" width="60" alt="Greptile logo" /> | 2026 |
|
||||
| [**Atlas Cloud**](https://www.atlascloud.ai/?utm_source=github&utm_medium=link&utm_campaign=ECC) | <picture><source media="(prefers-color-scheme: dark)" srcset="assets/images/sponsors/atlascloud-dark.svg" /><img src="assets/images/sponsors/atlascloud.svg" width="120" alt="Atlas Cloud logo" /></picture> | 2026 |
|
||||
| [**Moonshot AI (Kimi)**](https://www.moonshot.ai) | <picture><source media="(prefers-color-scheme: dark)" srcset="assets/images/sponsors/moonshot-dark.png" /><img src="assets/images/sponsors/moonshot.png" width="100" alt="Moonshot AI Kimi logo" /></picture> | 2026 |
|
||||
| [**Itô**](https://compute.itomarkets.com) | <picture><source media="(prefers-color-scheme: light)" srcset="assets/images/sponsors/ito-transparent-light.png" /><img src="assets/images/sponsors/ito-transparent.png" width="88" alt="Itô Markets logo" /></picture> | 2026 |
|
||||
| [**SerpApi**](https://serpapi.com/github-ecc) | <picture><source media="(prefers-color-scheme: dark)" srcset="assets/images/sponsors/serpapi-logo-dark-mode.svg" /><img src="assets/images/sponsors/serpapi-logo-light-mode.svg" width="200" alt="SerpApi: Web Search API" /></picture> | 2026 |
|
||||
|
||||
*[Become a Business sponsor](https://github.com/sponsors/affaan-m) to get README sponsor placement + SPONSORS.md listing. Current Business tier is $800/mo. No seats, SLA, custom development, or preferential technical placement is bundled unless separately agreed.*
|
||||
|
||||
Run or self-host any open-source model. Itô partners with ECC on compute, while ECC remains provider-agnostic and any GPU provider works. The [Itô dashboard](https://compute.itomarkets.com) sponsorship link is passive: it does not invoke an RFQ, reserve capacity, provision compute, or configure serving. Separately, the opt-in `ecc ito find` bridge invokes the explicitly configured canonical Itô CLI and submits a live authenticated RFQ; it does not reserve capacity. Managed inference through Itô is not live yet.
|
||||
|
||||
## Past Sponsors
|
||||
|
||||
| Sponsor | Active period |
|
||||
|---------|---------------|
|
||||
| [**Atlas Cloud**](https://www.atlascloud.ai/?utm_source=github&utm_medium=link&utm_campaign=ECC) | 2026 |
|
||||
|
||||
## Team Sponsors — $200/mo
|
||||
|
||||
| Sponsor | Since |
|
||||
|
||||
@@ -1,179 +0,0 @@
|
||||
# Working Context
|
||||
|
||||
Last updated: 2026-04-08
|
||||
|
||||
## Purpose
|
||||
|
||||
Public ECC plugin repo for agents, skills, commands, hooks, rules, install surfaces, and ECC 2.0 platform buildout.
|
||||
|
||||
## Current Truth
|
||||
|
||||
- Default branch: `main`
|
||||
- Public release surface is aligned at `v1.10.0`
|
||||
- Public catalog truth is `47` agents, `79` commands, and `181` skills
|
||||
- Public plugin slug is now `ecc`; legacy `everything-claude-code` install paths remain supported for compatibility
|
||||
- Release discussion: `#1272`
|
||||
- ECC 2.0 exists in-tree and builds, but it is still alpha rather than GA
|
||||
- Main active operational work:
|
||||
- keep default branch green
|
||||
- continue issue-driven fixes from `main` now that the public PR backlog is at zero
|
||||
- continue ECC 2.0 control-plane and operator-surface buildout
|
||||
|
||||
## Current Constraints
|
||||
|
||||
- No merge by title or commit summary alone.
|
||||
- No arbitrary external runtime installs in shipped ECC surfaces.
|
||||
- Overlapping skills, hooks, or agents should be consolidated when overlap is material and runtime separation is not required.
|
||||
|
||||
## Active Queues
|
||||
|
||||
- PR backlog: reduced but active; keep direct-porting only safe ECC-native changes and close overlap, stale generators, and unaudited external-runtime lanes
|
||||
- Upstream branch backlog still needs selective mining and cleanup:
|
||||
- `origin/feat/hermes-generated-ops-skills` still has three unique commits, but only reusable ECC-native skills should be salvaged from it
|
||||
- multiple `origin/ecc-tools/*` automation branches are stale and should be pruned after confirming they carry no unique value
|
||||
- Product:
|
||||
- selective install cleanup
|
||||
- control plane primitives
|
||||
- operator surface
|
||||
- self-improving skills
|
||||
- keep `agent.yaml` export parity with the shipped `commands/` and `skills/` directories so modern install surfaces do not silently lose command registration
|
||||
- Skill quality:
|
||||
- rewrite content-facing skills to use source-backed voice modeling
|
||||
- remove generic LLM rhetoric, canned CTA patterns, and forced platform stereotypes
|
||||
- continue one-by-one audit of overlapping or low-signal skill content
|
||||
- move repo guidance and contribution flow to skills-first, leaving commands only as explicit compatibility shims
|
||||
- add operator skills that wrap connected surfaces instead of exposing only raw APIs or disconnected primitives
|
||||
- land the canonical voice system, network-optimization lane, and reusable Manim explainer lane
|
||||
- Security:
|
||||
- keep dependency posture clean
|
||||
- preserve self-contained hook and MCP behavior
|
||||
|
||||
## Open PR Classification
|
||||
|
||||
- Closed on 2026-04-01 under backlog hygiene / merge policy:
|
||||
- `#1069` `feat: add everything-claude-code ECC bundle`
|
||||
- `#1068` `feat: add everything-claude-code-conventions ECC bundle`
|
||||
- `#1080` `feat: add everything-claude-code ECC bundle`
|
||||
- `#1079` `feat: add everything-claude-code-conventions ECC bundle`
|
||||
- `#1064` `chore(deps-dev): bump @eslint/js from 9.39.2 to 10.0.1`
|
||||
- `#1063` `chore(deps-dev): bump eslint from 9.39.2 to 10.1.0`
|
||||
- Closed on 2026-04-01 because the content is sourced from external ecosystems and should only land via manual ECC-native re-port:
|
||||
- `#852` openclaw-user-profiler
|
||||
- `#851` openclaw-soul-forge
|
||||
- `#640` harper skills
|
||||
- Native-support candidates to fully diff-audit next:
|
||||
- `#1055` Dart / Flutter support
|
||||
- `#1043` C# reviewer and .NET skills
|
||||
- Direct-port candidates landed after audit:
|
||||
- `#1078` hook-id dedupe for managed Claude hook reinstalls
|
||||
- `#844` ui-demo skill
|
||||
- `#1110` install-time Claude hook root resolution
|
||||
- `#1106` portable Codex Context7 key extraction
|
||||
- `#1107` Codex baseline merge and sample agent-role sync
|
||||
- `#1119` stale CI/lint cleanup that still contained safe low-risk fixes
|
||||
- Port or rebuild inside ECC after full audit:
|
||||
- `#894` Jira integration
|
||||
- `#814` + `#808` rebuild as a single consolidated notifications lane for Opencode and cross-harness surfaces
|
||||
|
||||
## Interfaces
|
||||
|
||||
- Public truth: GitHub issues and PRs
|
||||
- Internal execution truth: linked Linear work items under the ECC program
|
||||
- Current linked Linear items:
|
||||
- `ECC-206` ecosystem CI baseline
|
||||
- `ECC-207` PR backlog audit and merge-policy enforcement
|
||||
- `ECC-208` context hygiene
|
||||
- `ECC-210` skills-first workflow migration and command compatibility retirement
|
||||
|
||||
## Update Rule
|
||||
|
||||
Keep this file detailed for only the current sprint, blockers, and next actions. Summarize completed work into archive or repo docs once it is no longer actively shaping execution.
|
||||
|
||||
## Latest Execution Notes
|
||||
|
||||
- 2026-04-05: Continued `#1213` overlap cleanup by narrowing `coding-standards` into the baseline cross-project conventions layer instead of deleting it. The skill now explicitly points detailed React/UI guidance to `frontend-patterns`, backend/API structure to `backend-patterns` / `api-design`, and keeps only reusable naming, readability, immutability, and code-quality expectations.
|
||||
- 2026-04-05: Added a packaging regression guard for the OpenCode release path after `#1287` showed the published `v1.10.0` artifact was still stale. `tests/scripts/build-opencode.test.js` now asserts the `npm pack --dry-run` tarball includes `.opencode/dist/index.js` plus compiled plugin/tool entrypoints, so future releases cannot silently omit the built OpenCode payload.
|
||||
- 2026-04-05: Landed `skills/agent-introspection-debugging` for `#829` as an ECC-native self-debugging framework. It is intentionally guidance-first rather than fake runtime automation: capture failure state, classify the pattern, apply the smallest contained recovery action, then emit a structured introspection report and hand off to `verification-loop` / `continuous-learning-v2` when appropriate.
|
||||
- 2026-04-05: Fixed the `main` npm CI break after the latest direct ports. `package-lock.json` had drifted behind `package.json` on the `globals` devDependency (`^17.1.0` vs `^17.4.0`), which caused all npm-based GitHub Actions jobs to fail at `npm ci`. Refreshed the lockfile only, verified `npm ci --ignore-scripts`, and kept the mixed-lock workspace otherwise untouched.
|
||||
- 2026-04-05: Direct-ported the useful discoverability part of `#1221` without duplicating a second healthcare compliance system. Added `skills/hipaa-compliance/SKILL.md` as a thin HIPAA-specific entrypoint that points into the canonical `healthcare-phi-compliance` / `healthcare-reviewer` lane, and wired both healthcare privacy skills into the `security` install module for selective installs.
|
||||
- 2026-04-05: Direct-ported the audited blockchain/web3 security lane from `#1222` into `main` as four self-contained skills: `defi-amm-security`, `evm-token-decimals`, `llm-trading-agent-security`, and `nodejs-keccak256`. These are now part of the `security` install module instead of living as an unmerged fork PR.
|
||||
- 2026-04-05: Finished the useful salvage pass from `#1203` directly on `main`. `skills/security-bounty-hunter`, `skills/api-connector-builder`, and `skills/dashboard-builder` are now in-tree as ECC-native rewrites instead of the thinner original community drafts. The original PR should be treated as superseded rather than merged.
|
||||
- 2026-04-02: `ECC-Tools/main` shipped `9566637` (`fix: prefer commit lookup over git ref resolution`). The PR-analysis fire is now fixed in the app repo by preferring explicit commit resolution before `git.getRef`, with regression coverage for pull refs and plain branch refs. Mirrored public tracking issue `#1184` in this repo was closed as resolved upstream.
|
||||
- 2026-04-02: Direct-ported the clean native-support core of `#1043` into `main`: `agents/csharp-reviewer.md`, `skills/dotnet-patterns/SKILL.md`, and `skills/csharp-testing/SKILL.md`. This fills the gap between existing C# rule/docs mentions and actual shipped C# review/testing guidance.
|
||||
- 2026-04-02: Direct-ported the clean native-support core of `#1055` into `main`: `agents/dart-build-resolver.md`, `commands/flutter-build.md`, `commands/flutter-review.md`, `commands/flutter-test.md`, `rules/dart/*`, and `skills/dart-flutter-patterns/SKILL.md`. The skill paths were wired into the current `framework-language` module instead of replaying the older PR's separate `flutter-dart` module layout.
|
||||
- 2026-04-02: Closed `#1081` after diff audit. The PR only added vendor-marketing docs for an external X/Twitter backend (`Xquik` / `x-twitter-scraper`) to the canonical `x-api` skill instead of contributing an ECC-native capability.
|
||||
- 2026-04-02: Direct-ported the useful Jira lane from `#894`, but sanitized it to match current supply-chain policy. `commands/jira.md`, `skills/jira-integration/SKILL.md`, and the pinned `jira` MCP template in `mcp-configs/mcp-servers.json` are in-tree, while the skill no longer tells users to install `uv` via `curl | bash`. `jira-integration` is classified under `operator-workflows` for selective installs.
|
||||
- 2026-04-02: Closed `#1125` after full diff audit. The bundle/skill-router lane hardcoded many non-existent or non-canonical surfaces and created a second routing abstraction instead of a small ECC-native index layer.
|
||||
- 2026-04-02: Closed `#1124` after full diff audit. The added agent roster was thoughtfully written, but it duplicated the existing ECC agent surface with a second competing catalog (`dispatch`, `explore`, `verifier`, `executor`, etc.) instead of strengthening canonical agents already in-tree.
|
||||
- 2026-04-02: Closed the full Argus cluster `#1098`, `#1099`, `#1100`, `#1101`, and `#1102` after full diff audit. The common failure mode was the same across all five PRs: external multi-CLI dispatch was treated as a first-class runtime dependency of shipped ECC surfaces. Any useful protocol ideas should be re-ported later into ECC-native orchestration, review, or reflection lanes without external CLI fan-out assumptions.
|
||||
- 2026-04-02: The previously open native-support / integration queue (`#1081`, `#1055`, `#1043`, `#894`) has now been fully resolved by direct-port or closure policy. The active public PR queue is currently zero; next focus stays on issue-driven mainline fixes and CI health, not backlog PR intake.
|
||||
- 2026-04-01: `main` CI was restored locally with `1723/1723` tests passing after lockfile and hook validation fixes.
|
||||
- 2026-04-01: Auto-generated ECC bundle PRs `#1068` and `#1069` were closed instead of merged; useful ideas must be ported manually after explicit diff audit.
|
||||
- 2026-04-01: Major-version ESLint bump PRs `#1063` and `#1064` were closed; revisit only inside a planned ESLint 10 migration lane.
|
||||
- 2026-04-01: Notification PRs `#808` and `#814` were identified as overlapping and should be rebuilt as one unified feature instead of landing as parallel branches.
|
||||
- 2026-04-01: External-source skill PRs `#640`, `#851`, and `#852` were closed under the new ingestion policy; copy ideas from audited source later rather than merging branded/source-import PRs directly.
|
||||
- 2026-04-01: The remaining low GitHub advisory on `ecc2/Cargo.lock` was addressed by moving `ratatui` to `0.30` with `crossterm_0_28`, which updated transitive `lru` from `0.12.5` to `0.16.3`. `cargo build --manifest-path ecc2/Cargo.toml` still passes.
|
||||
- 2026-04-01: Safe core of `#834` was ported directly into `main` instead of merging the PR wholesale. This included stricter install-plan validation, antigravity target filtering that skips unsupported module trees, tracked catalog sync for English plus zh-CN docs, and a dedicated `catalog:sync` write mode.
|
||||
- 2026-04-01: Repo catalog truth is now synced at `36` agents, `68` commands, and `142` skills across the tracked English and zh-CN docs.
|
||||
- 2026-04-01: Legacy emoji and non-essential symbol usage in docs, scripts, and tests was normalized to keep the unicode-safety lane green without weakening the check itself.
|
||||
- 2026-04-01: The remaining self-contained piece of `#834`, `docs/zh-CN/skills/browser-qa/SKILL.md`, was ported directly into the repo. After commit, `#834` should be closed as superseded-by-direct-port.
|
||||
- 2026-04-01: Content skill cleanup started with `content-engine`, `crosspost`, `article-writing`, and `investor-outreach`. The new direction is source-first voice capture, explicit anti-trope bans, and no forced platform persona shifts.
|
||||
- 2026-04-01: `node scripts/ci/check-unicode-safety.js --write` sanitized the remaining emoji-bearing Markdown files, including several `remotion-video-creation` rule docs and an old local plan note.
|
||||
- 2026-04-01: Core English repo surfaces were shifted to a skills-first posture. README, AGENTS, plugin metadata, and contributor instructions now treat `skills/` as canonical and `commands/` as legacy slash-entry compatibility during migration.
|
||||
- 2026-04-01: Follow-up bundle cleanup closed `#1080` and `#1079`, which were generated `.claude/` bundle PRs duplicating command-first scaffolding instead of shipping canonical ECC source changes.
|
||||
- 2026-04-01: Ported the useful core of `#1078` directly into `main`, but tightened the implementation so legacy no-id hook installs deduplicate cleanly on the first reinstall instead of the second. Added stable hook ids to `hooks/hooks.json`, semantic fallback aliases in `mergeHookEntries()`, and a regression test covering upgrade from pre-id settings.
|
||||
- 2026-04-01: Collapsed the obvious command/skill duplicates into thin legacy shims so `skills/` now hold the maintained bodies for NanoClaw, context-budget, DevFleet, docs lookup, E2E, evals, orchestration, prompt optimization, rules distillation, TDD, and verification.
|
||||
- 2026-04-01: Ported the self-contained core of `#844` directly into `main` as `skills/ui-demo/SKILL.md` and registered it under the `media-generation` install module instead of merging the PR wholesale.
|
||||
- 2026-04-01: Added the first connected-workflow operator lane as ECC-native skills instead of leaving the surface as raw plugins or APIs: `workspace-surface-audit`, `customer-billing-ops`, `project-flow-ops`, and `google-workspace-ops`. These are tracked under the new `operator-workflows` install module.
|
||||
- 2026-04-01: Direct-ported the real fix from the unresolved hook-path PR lane into the active installer. Claude installs now replace `${CLAUDE_PLUGIN_ROOT}` with the concrete install root in both `settings.json` and the copied `hooks/hooks.json`, which keeps PreToolUse/PostToolUse hooks working outside plugin-managed env injection.
|
||||
- 2026-04-01: Replaced the GNU-only `grep -P` parser in `scripts/sync-ecc-to-codex.sh` with a portable Node parser for Context7 key extraction. Added source-level regression coverage so BSD/macOS syncs do not drift back to non-portable parsing.
|
||||
- 2026-04-01: Targeted regression suite after the direct ports is green: `tests/scripts/install-apply.test.js`, `tests/scripts/sync-ecc-to-codex.test.js`, and `tests/scripts/codex-hooks.test.js`.
|
||||
- 2026-04-01: Ported the useful core of `#1107` directly into `main` as an add-only Codex baseline merge. `scripts/sync-ecc-to-codex.sh` now fills missing non-MCP defaults from `.codex/config.toml`, syncs sample agent role files into `~/.codex/agents`, and preserves user config instead of replacing it. Added regression coverage for sparse configs and implicit parent tables.
|
||||
- 2026-04-01: Ported the safe low-risk cleanup from `#1119` directly into `main` instead of keeping an obsolete CI PR open. This included `.mjs` eslint handling, stricter null checks, Windows home-dir coverage in bash-log tests, and longer Trae shell-test timeouts.
|
||||
- 2026-04-01: Added `brand-voice` as the canonical source-derived writing-style system and wired the content lane to treat it as the shared voice source of truth instead of duplicating partial style heuristics across skills.
|
||||
- 2026-04-01: Added `connections-optimizer` as the review-first social-graph reorganization workflow for X and LinkedIn, with explicit pruning modes, browser fallback expectations, and Apple Mail drafting guidance.
|
||||
- 2026-04-01: Added `manim-video` as the reusable technical explainer lane and seeded it with a starter network-graph scene so launch and systems animations do not depend on one-off scratch scripts.
|
||||
- 2026-04-02: Re-extracted `social-graph-ranker` as a standalone primitive because the weighted bridge-decay model is reusable outside the full lead workflow. `lead-intelligence` now points to it for canonical graph ranking instead of carrying the full algorithm explanation inline, while `connections-optimizer` stays the broader operator layer for pruning, adds, and outbound review packs.
|
||||
- 2026-04-02: Applied the same consolidation rule to the writing lane. `brand-voice` remains the canonical voice system, while `content-engine`, `crosspost`, `article-writing`, and `investor-outreach` now keep only workflow-specific guidance instead of duplicating a second Affaan/ECC voice model or repeating the full ban list in multiple places.
|
||||
- 2026-04-02: Closed fresh auto-generated bundle PRs `#1182` and `#1183` under the existing policy. Useful ideas from generator output must be ported manually into canonical repo surfaces instead of merging `.claude`/bundle PRs wholesale.
|
||||
- 2026-04-02: Ported the safe one-file macOS observer fix from `#1164` directly into `main` as a POSIX `mkdir` fallback for `continuous-learning-v2` lazy-start locking, then closed the PR as superseded by direct port.
|
||||
- 2026-04-02: Ported the safe core of `#1153` directly into `main`: markdownlint cleanup for orchestration/docs surfaces plus the Windows `USERPROFILE` and path-normalization fixes in `install-apply` / `repair` tests. Local validation after installing repo deps: `node tests/scripts/install-apply.test.js`, `node tests/scripts/repair.test.js`, and targeted `yarn markdownlint` all passed.
|
||||
- 2026-04-02: Direct-ported the safe web/frontend rules lane from `#1122` into `rules/web/`, but adapted `rules/web/hooks.md` to prefer project-local tooling and avoid remote one-off package execution examples.
|
||||
- 2026-04-02: Adapted the design-quality reminder from `#1127` into the current ECC hook architecture with a local `scripts/hooks/design-quality-check.js`, Claude `hooks/hooks.json` wiring, Cursor `after-file-edit.js` wiring, and dedicated hook coverage in `tests/hooks/design-quality-check.test.js`.
|
||||
- 2026-04-02: Fixed `#1141` on `main` in `16e9b17`. The observer lifecycle is now session-aware instead of purely detached: `SessionStart` writes a project-scoped lease, `SessionEnd` removes that lease and stops the observer when the final lease disappears, `observe.sh` records project activity, and `observer-loop.sh` now exits on idle when no leases remain. Targeted validation passed with `bash -n`, `node tests/hooks/observer-memory.test.js`, `node tests/integration/hooks.test.js`, `node scripts/ci/validate-hooks.js hooks/hooks.json`, and `node scripts/ci/check-unicode-safety.js`.
|
||||
- 2026-04-02: Fixed the remaining Windows-only hook regression behind `#1070` by making `scripts/lib/utils.js#getHomeDir()` honor explicit `HOME` / `USERPROFILE` overrides before falling back to `os.homedir()`. This restores test-isolated observer state paths for hook integration runs on Windows. Added regression coverage in `tests/lib/utils.test.js`. Targeted validation passed with `node tests/lib/utils.test.js`, `node tests/integration/hooks.test.js`, `node tests/hooks/observer-memory.test.js`, and `node scripts/ci/check-unicode-safety.js`.
|
||||
- 2026-04-02: Direct-ported NestJS support for `#1022` into `main` as `skills/nestjs-patterns/SKILL.md` and wired it into the `framework-language` install module. Synced the repo catalog afterward (`38` agents, `72` commands, `156` skills) and updated the docs so NestJS is no longer listed as an unfilled framework gap.
|
||||
- 2026-04-05: Shipped `846ffb7` (`chore: ship v1.10.0 release surface refresh`). This updated README/plugin metadata/package versions, synced the explicit plugin agent inventory, bumped stale star/fork/contributor counts, created `docs/releases/1.10.0/*`, tagged and released `v1.10.0`, and posted the announcement discussion at `#1272`.
|
||||
- 2026-04-05: Salvaged the reusable Hermes-branch operator skills in `6eba30f` without replaying the full branch. Added `skills/github-ops`, `skills/knowledge-ops`, and `skills/hookify-rules`, wired them into install modules, and re-synced the repo to `159` skills. `knowledge-ops` was explicitly adapted to the current workspace model: live code in cloned repos, active truth in GitHub/Linear, broader non-code context in the KB/archive layers.
|
||||
- 2026-04-05: Fixed the remaining OpenCode npm-publish gap in `db6d52e`. The root package now builds `.opencode/dist` during `prepack`, includes the compiled OpenCode plugin assets in the published tarball, and carries a dedicated regression test (`tests/scripts/build-opencode.test.js`) so the package no longer ships only raw TypeScript source for that surface.
|
||||
- 2026-04-05: Added `skills/council`, direct-ported the safe `code-tour` lane from `#1193`, and re-synced the repo to `162` skills. `code-tour` stays self-contained and only produces `.tours/*.tour` artifacts with real file/line anchors; no external runtime or extension install is assumed inside the skill.
|
||||
- 2026-04-05: Closed the latest auto-generated ECC bundle PR wave (`#1275`-`#1281`) after deploying `ECC-Tools/main` fix `f615905`, which now blocks repo-level issue-comment `/analyze` requests from opening repeated bundle PRs while still allowing PR-thread retry analysis to run against immutable head SHAs.
|
||||
- 2026-04-05: Filled the SEO gap by direct-porting `agents/seo-specialist.md` and `skills/seo/SKILL.md` into `main`, then wiring `skills/seo` into `business-content`. This resolves the stale `team-builder` reference to an SEO specialist and brings the public catalog to `39` agents and `163` skills without merging the stale PR wholesale.
|
||||
- 2026-04-05: Salvaged the useful common-rule deltas from `#1214` directly into `rules/common/coding-style.md` and `rules/common/testing.md` (KISS/DRY/YAGNI reminders, naming conventions, code-smell guidance, and AAA-style test guidance), then closed the original mixed deletion PR. The broad skill removals in that PR were intentionally not replayed.
|
||||
- 2026-04-05: Fixed the stale-row bug in `.github/workflows/monthly-metrics.yml` with `bf5961e`. The workflow now refreshes the current month row in issue `#1087` instead of early-returning when the month already exists, and the dispatched run updated the April snapshot to the current star/fork/release counts.
|
||||
- 2026-04-05: Recovered the useful cost-control workflow from the divergent Hermes branch as a small ECC-native operator skill instead of replaying the branch. `skills/ecc-tools-cost-audit/SKILL.md` is now wired into `operator-workflows` and focused on webhook -> queue -> worker tracing, burn containment, quota bypass, premium-model leakage, and retry fanout in the sibling `ECC-Tools` repo.
|
||||
- 2026-04-05: Added `skills/council/SKILL.md` in `753da37` as an ECC-native four-voice decision workflow. The useful protocol from PR `#1254` was retained, but the shadow `~/.claude/notes` write path was explicitly removed in favor of `knowledge-ops`, `/save-session`, or direct GitHub/Linear updates when a decision delta matters.
|
||||
- 2026-04-05: Direct-ported the safe `globals` bump from PR `#1243` into `main` as part of the council lane and closed the PR as superseded.
|
||||
- 2026-04-05: Closed PR `#1232` after full audit. The proposed `skill-scout` workflow overlaps current `search-first`, `/skill-create`, and `skill-stocktake`; if a dedicated marketplace-discovery layer returns later it should be rebuilt on top of the current install/catalog model rather than landing as a parallel discovery path.
|
||||
- 2026-04-05: Ported the safe localized README switcher fixes from PR `#1209` directly into `main` rather than merging the docs PR wholesale. The navigation now consistently includes `Português (Brasil)` and `Türkçe` across the localized README switchers, while newer localized body copy stays intact.
|
||||
- 2026-04-05: Removed the stale InsAIts shipped surface from `main`. ECC no longer ships the external Python MCP entry, opt-in hook wiring, wrapper/monitor scripts, or current docs mentions for `insa-its`; changelog history remains, but the live product surface is now fully ECC-native again.
|
||||
- 2026-04-05: Salvaged the reusable Hermes-generated operator workflow lane without replaying the whole branch. Added six ECC-native top-level skills instead of the old nested `skills/hermes-generated/*` tree: `automation-audit-ops`, `email-ops`, `finance-billing-ops`, `messages-ops`, `research-ops`, and `terminal-ops`. `research-ops` now wraps the existing research stack, while the other five extend `operator-workflows` without introducing any external runtime assumptions.
|
||||
- 2026-04-05: Added `skills/product-capability` plus `docs/examples/product-capability-template.md` as the canonical PRD-to-SRS lane for issue `#1185`. This is the ECC-native capability-contract step between vague product intent and implementation, and it lives in `business-content` rather than spawning a parallel planning subsystem.
|
||||
- 2026-04-05: Tightened `product-lens` so it no longer overlaps the new capability-contract lane. `product-lens` now explicitly owns product diagnosis / brief validation, while `product-capability` owns implementation-ready capability plans and SRS-style constraints.
|
||||
- 2026-04-05: Continued `#1213` cleanup by removing stale references to the deleted `project-guidelines-example` skill from exported inventory/docs and marking `continuous-learning` v1 as a supported legacy path with an explicit handoff to `continuous-learning-v2`.
|
||||
- 2026-04-05: Removed the last orphaned localized `project-guidelines-example` docs from `docs/ko-KR` and `docs/zh-CN`. The template now lives only in `docs/examples/project-guidelines-template.md`, which matches the current repo surface and avoids shipping translated docs for a deleted skill.
|
||||
- 2026-04-05: Added `docs/HERMES-OPENCLAW-MIGRATION.md` as the current public migration guide for issue `#1051`. It reframes Hermes/OpenClaw as source systems to distill from, not the final runtime, and maps scheduler, dispatch, memory, skill, and service layers onto the ECC-native surfaces and ECC 2.0 backlog that already exist.
|
||||
- 2026-04-05: Landed `skills/agent-sort` and the legacy `/agent-sort` shim from issue `#916` as an ECC-native selective-install workflow. It classifies agents, skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using concrete repo evidence, then hands off installation changes to `configure-ecc` instead of inventing a parallel installer. Catalog truth is now `39` agents, `73` commands, and `179` skills.
|
||||
- 2026-04-05: Direct-ported the safe README-only `#1285` slice into `main` instead of merging the branch: added a small `Community Projects` section so downstream teams can link public work built on ECC without changing install, security, or runtime surfaces. Rejected `#1286` at review because it adds an external third-party GitHub Action (`hashgraph-online/codex-plugin-scanner`) that does not meet the current supply-chain policy.
|
||||
- 2026-04-05: Re-audited `origin/feat/hermes-generated-ops-skills` by full diff. The branch is still not mergeable: it deletes current ECC-native surfaces, regresses packaging/install metadata, and removes newer `main` content. Continued the selective-salvage policy instead of branch merge.
|
||||
- 2026-04-05: Selectively salvaged `skills/frontend-design` from the Hermes branch as a self-contained ECC-native skill, mirrored it into `.agents`, wired it into `framework-language`, and re-synced the catalog to `180` skills after validation. The branch itself remains reference-only until every remaining unique file is either ported intentionally or rejected.
|
||||
- 2026-04-05: Selectively salvaged the `hookify` command bundle plus the supporting `conversation-analyzer` agent from the Hermes branch. `hookify-rules` already existed as the canonical skill; this pass restores the user-facing command surfaces (`/hookify`, `/hookify-help`, `/hookify-list`, `/hookify-configure`) without pulling in any external runtime or branch-wide regressions. Catalog truth is now `40` agents, `77` commands, and `180` skills.
|
||||
- 2026-04-05: Selectively salvaged the self-contained review/development bundle from the Hermes branch: `review-pr`, `feature-dev`, and the supporting analyzer/architecture agents (`code-architect`, `code-explorer`, `code-simplifier`, `comment-analyzer`, `pr-test-analyzer`, `silent-failure-hunter`, `type-design-analyzer`). This adds ECC-native command surfaces around PR review and feature planning without merging the branch's broader regressions. Catalog truth is now `47` agents, `79` commands, and `180` skills.
|
||||
- 2026-04-05: Ported `docs/HERMES-SETUP.md` from the Hermes branch as a sanitized operator-topology document for the migration lane. This is docs-only support for `#1051`, not a runtime change and not a sign that the Hermes branch itself is mergeable.
|
||||
- 2026-04-05: Finished the useful salvage pass over `origin/feat/hermes-generated-ops-skills`. The remaining unique files were explicitly rejected:
|
||||
- duplicate git helper commands (`commit`, `commit-push-pr`, `clean-gone`) overlap current checkpoint / publish flows
|
||||
- `scripts/hooks/security-reminder*` adds a new Python-backed hook path not justified by current runtime policy
|
||||
- `skills/oura-health` and `skills/pmx-guidelines` are user- or project-specific, not canonical ECC surfaces
|
||||
- `docs/releases/2.0.0-preview/*` is premature collateral and should be rebuilt from current product truth later
|
||||
- nested `skills/hermes-generated/*` is superseded by the top-level ECC-native operator skills already ported to `main`
|
||||
- 2026-04-08: Fixed the command-export regression reported in `#1327` by restoring a canonical `commands:` section in `agent.yaml` and adding `tests/ci/agent-yaml-surface.test.js` to enforce exact parity between the YAML export surface and the real `commands/` directory. Verified with the full repo test sweep: `1764/1764` passing.
|
||||
+8
-2
@@ -1,6 +1,6 @@
|
||||
spec_version: "0.1.0"
|
||||
name: ecc
|
||||
version: 2.2.1
|
||||
version: 2.2.2
|
||||
description: "Initial gitagent export surface for ECC's shared skill catalog, governance, and identity. Native agents, commands, and hooks remain authoritative in the repository while manifest coverage expands."
|
||||
author: affaan-m
|
||||
license: MIT
|
||||
@@ -100,7 +100,9 @@ skills:
|
||||
- logistics-exception-management
|
||||
- market-research
|
||||
- mcp-server-patterns
|
||||
- motion-ui
|
||||
- motion-advanced
|
||||
- motion-foundations
|
||||
- motion-patterns
|
||||
- nanoclaw-repl
|
||||
- nextjs-turbopack
|
||||
- nutrient-document-processing
|
||||
@@ -123,6 +125,7 @@ skills:
|
||||
- quarkus-security
|
||||
- quarkus-tdd
|
||||
- quarkus-verification
|
||||
- rails-patterns
|
||||
- ralphinho-rfc-pipeline
|
||||
- react-patterns
|
||||
- react-performance
|
||||
@@ -149,6 +152,9 @@ skills:
|
||||
- swift-concurrency-6-2
|
||||
- swift-protocol-di-testing
|
||||
- swiftui-patterns
|
||||
- taste-application
|
||||
- taste-distillation
|
||||
- tasteforge-video
|
||||
- tdd-workflow
|
||||
- team-builder
|
||||
- token-budget-advisor
|
||||
|
||||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 7.8 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 7.5 KiB |
@@ -1,30 +0,0 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 400" width="800" height="400" font-family="-apple-system,BlinkMacSystemFont,Segoe UI,Helvetica,Arial,sans-serif">
|
||||
<rect width="800" height="400" fill="#0d1117"/>
|
||||
<line x1="70" y1="348.0" x2="772" y2="348.0" stroke="#30363d" stroke-width="1"/>
|
||||
<text x="60" y="352.0" fill="#8b949e" font-size="12" text-anchor="end">0</text>
|
||||
<line x1="70" y1="284.4" x2="772" y2="284.4" stroke="#30363d" stroke-width="1"/>
|
||||
<text x="60" y="288.4" fill="#8b949e" font-size="12" text-anchor="end">10k</text>
|
||||
<line x1="70" y1="220.8" x2="772" y2="220.8" stroke="#30363d" stroke-width="1"/>
|
||||
<text x="60" y="224.8" fill="#8b949e" font-size="12" text-anchor="end">20k</text>
|
||||
<line x1="70" y1="157.2" x2="772" y2="157.2" stroke="#30363d" stroke-width="1"/>
|
||||
<text x="60" y="161.2" fill="#8b949e" font-size="12" text-anchor="end">30k</text>
|
||||
<line x1="70" y1="93.6" x2="772" y2="93.6" stroke="#30363d" stroke-width="1"/>
|
||||
<text x="60" y="97.6" fill="#8b949e" font-size="12" text-anchor="end">40k</text>
|
||||
<line x1="70" y1="30.0" x2="772" y2="30.0" stroke="#30363d" stroke-width="1"/>
|
||||
<text x="60" y="34.0" fill="#8b949e" font-size="12" text-anchor="end">50k</text>
|
||||
<line x1="70.0" y1="30" x2="70.0" y2="348" stroke="#30363d" stroke-width="1" stroke-dasharray="2 4"/>
|
||||
<text x="70.0" y="370" fill="#8b949e" font-size="12" text-anchor="middle">Jan 18</text>
|
||||
<line x1="238.7" y1="30" x2="238.7" y2="348" stroke="#30363d" stroke-width="1" stroke-dasharray="2 4"/>
|
||||
<text x="238.7" y="370" fill="#8b949e" font-size="12" text-anchor="middle">Jan 23</text>
|
||||
<line x1="407.3" y1="30" x2="407.3" y2="348" stroke="#30363d" stroke-width="1" stroke-dasharray="2 4"/>
|
||||
<text x="407.3" y="370" fill="#8b949e" font-size="12" text-anchor="middle">Jan 28</text>
|
||||
<line x1="576.0" y1="30" x2="576.0" y2="348" stroke="#30363d" stroke-width="1" stroke-dasharray="2 4"/>
|
||||
<text x="576.0" y="370" fill="#8b949e" font-size="12" text-anchor="middle">Feb 2</text>
|
||||
<line x1="744.7" y1="30" x2="744.7" y2="348" stroke="#30363d" stroke-width="1" stroke-dasharray="2 4"/>
|
||||
<text x="744.7" y="370" fill="#8b949e" font-size="12" text-anchor="middle">Feb 7</text>
|
||||
<polygon points="70,348 70.0,348.0 123.9,332.7 137.9,327.6 149.4,322.6 171.9,307.3 177.3,302.2 187.8,292.0 192.2,286.9 198.6,281.8 212.6,266.6 222.0,256.4 226.3,251.3 234.5,246.2 239.6,241.1 244.2,236.1 247.5,231.0 251.4,225.9 274.2,210.6 282.2,205.5 290.0,200.4 300.7,195.4 312.3,190.3 320.2,185.2 355.4,164.8 373.7,159.7 409.0,149.6 430.4,144.5 458.7,139.4 492.0,134.3 526.5,129.2 559.4,124.1 618.6,113.9 685.6,103.8 718.9,98.7 772.0,93.6 772,348" fill="#2ea04326"/>
|
||||
<polyline points="70.0,348.0 123.9,332.7 137.9,327.6 149.4,322.6 171.9,307.3 177.3,302.2 187.8,292.0 192.2,286.9 198.6,281.8 212.6,266.6 222.0,256.4 226.3,251.3 234.5,246.2 239.6,241.1 244.2,236.1 247.5,231.0 251.4,225.9 274.2,210.6 282.2,205.5 290.0,200.4 300.7,195.4 312.3,190.3 320.2,185.2 355.4,164.8 373.7,159.7 409.0,149.6 430.4,144.5 458.7,139.4 492.0,134.3 526.5,129.2 559.4,124.1 618.6,113.9 685.6,103.8 718.9,98.7 772.0,93.6" fill="none" stroke="#2ea043" stroke-width="2.5" stroke-linejoin="round" stroke-linecap="round"/>
|
||||
<circle cx="772.0" cy="93.6" r="4" fill="#2ea043"/>
|
||||
<text x="400.0" y="20" fill="#e6edf3" font-size="14" font-weight="600" text-anchor="middle">affaan-m/ECC · first 40,000 stars</text>
|
||||
<text x="70" y="390" fill="#8b949e" font-size="11">Jan 18, 2026 – Feb 7, 2026 · source: GitHub stargazers API</text>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 3.4 KiB |
@@ -1,30 +0,0 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 400" width="800" height="400" font-family="-apple-system,BlinkMacSystemFont,Segoe UI,Helvetica,Arial,sans-serif">
|
||||
<rect width="800" height="400" fill="#ffffff"/>
|
||||
<line x1="70" y1="348.0" x2="772" y2="348.0" stroke="#d8dee4" stroke-width="1"/>
|
||||
<text x="60" y="352.0" fill="#59636e" font-size="12" text-anchor="end">0</text>
|
||||
<line x1="70" y1="284.4" x2="772" y2="284.4" stroke="#d8dee4" stroke-width="1"/>
|
||||
<text x="60" y="288.4" fill="#59636e" font-size="12" text-anchor="end">10k</text>
|
||||
<line x1="70" y1="220.8" x2="772" y2="220.8" stroke="#d8dee4" stroke-width="1"/>
|
||||
<text x="60" y="224.8" fill="#59636e" font-size="12" text-anchor="end">20k</text>
|
||||
<line x1="70" y1="157.2" x2="772" y2="157.2" stroke="#d8dee4" stroke-width="1"/>
|
||||
<text x="60" y="161.2" fill="#59636e" font-size="12" text-anchor="end">30k</text>
|
||||
<line x1="70" y1="93.6" x2="772" y2="93.6" stroke="#d8dee4" stroke-width="1"/>
|
||||
<text x="60" y="97.6" fill="#59636e" font-size="12" text-anchor="end">40k</text>
|
||||
<line x1="70" y1="30.0" x2="772" y2="30.0" stroke="#d8dee4" stroke-width="1"/>
|
||||
<text x="60" y="34.0" fill="#59636e" font-size="12" text-anchor="end">50k</text>
|
||||
<line x1="70.0" y1="30" x2="70.0" y2="348" stroke="#d8dee4" stroke-width="1" stroke-dasharray="2 4"/>
|
||||
<text x="70.0" y="370" fill="#59636e" font-size="12" text-anchor="middle">Jan 18</text>
|
||||
<line x1="238.7" y1="30" x2="238.7" y2="348" stroke="#d8dee4" stroke-width="1" stroke-dasharray="2 4"/>
|
||||
<text x="238.7" y="370" fill="#59636e" font-size="12" text-anchor="middle">Jan 23</text>
|
||||
<line x1="407.3" y1="30" x2="407.3" y2="348" stroke="#d8dee4" stroke-width="1" stroke-dasharray="2 4"/>
|
||||
<text x="407.3" y="370" fill="#59636e" font-size="12" text-anchor="middle">Jan 28</text>
|
||||
<line x1="576.0" y1="30" x2="576.0" y2="348" stroke="#d8dee4" stroke-width="1" stroke-dasharray="2 4"/>
|
||||
<text x="576.0" y="370" fill="#59636e" font-size="12" text-anchor="middle">Feb 2</text>
|
||||
<line x1="744.7" y1="30" x2="744.7" y2="348" stroke="#d8dee4" stroke-width="1" stroke-dasharray="2 4"/>
|
||||
<text x="744.7" y="370" fill="#59636e" font-size="12" text-anchor="middle">Feb 7</text>
|
||||
<polygon points="70,348 70.0,348.0 123.9,332.7 137.9,327.6 149.4,322.6 171.9,307.3 177.3,302.2 187.8,292.0 192.2,286.9 198.6,281.8 212.6,266.6 222.0,256.4 226.3,251.3 234.5,246.2 239.6,241.1 244.2,236.1 247.5,231.0 251.4,225.9 274.2,210.6 282.2,205.5 290.0,200.4 300.7,195.4 312.3,190.3 320.2,185.2 355.4,164.8 373.7,159.7 409.0,149.6 430.4,144.5 458.7,139.4 492.0,134.3 526.5,129.2 559.4,124.1 618.6,113.9 685.6,103.8 718.9,98.7 772.0,93.6 772,348" fill="#1a7f3720"/>
|
||||
<polyline points="70.0,348.0 123.9,332.7 137.9,327.6 149.4,322.6 171.9,307.3 177.3,302.2 187.8,292.0 192.2,286.9 198.6,281.8 212.6,266.6 222.0,256.4 226.3,251.3 234.5,246.2 239.6,241.1 244.2,236.1 247.5,231.0 251.4,225.9 274.2,210.6 282.2,205.5 290.0,200.4 300.7,195.4 312.3,190.3 320.2,185.2 355.4,164.8 373.7,159.7 409.0,149.6 430.4,144.5 458.7,139.4 492.0,134.3 526.5,129.2 559.4,124.1 618.6,113.9 685.6,103.8 718.9,98.7 772.0,93.6" fill="none" stroke="#1a7f37" stroke-width="2.5" stroke-linejoin="round" stroke-linecap="round"/>
|
||||
<circle cx="772.0" cy="93.6" r="4" fill="#1a7f37"/>
|
||||
<text x="400.0" y="20" fill="#1f2328" font-size="14" font-weight="600" text-anchor="middle">affaan-m/ECC · first 40,000 stars</text>
|
||||
<text x="70" y="390" fill="#59636e" font-size="11">Jan 18, 2026 – Feb 7, 2026 · source: GitHub stargazers API</text>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 3.4 KiB |
@@ -158,3 +158,5 @@ Next step: /plan .claude/prds/{name}.prd.md
|
||||
- **HYPOTHESIS_TESTABLE**: measurable outcome included.
|
||||
- **SCOPE_BOUNDED**: explicit MVP and explicit out-of-scope.
|
||||
- **NO_IMPLEMENTATION_DETAIL**: file paths, libraries, or task breakdowns are absent — if they appeared, move them to the `/plan` step.
|
||||
|
||||
Background on the staged markdown flow: [docs/PLAN-PRD-PATTERN.md](../docs/PLAN-PRD-PATTERN.md).
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
description: "Create a GitHub PR from current branch with unpushed commits — discovers templates, analyzes changes, pushes"
|
||||
description: "Alias of /pr for the PRP workflow series. Use when creating a pull request mid-PRP workflow; otherwise use /pr."
|
||||
argument-hint: "[base-branch] (default: main)"
|
||||
---
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ slash-command harnesses can reach it.
|
||||
## What it does
|
||||
|
||||
Renders an SVG card of this machine's AI coding agent usage — tokens, equivalent cost,
|
||||
streak, per-agent split — from local Claude Code, Codex and OpenCode session logs, and writes
|
||||
streak, per-agent split — from local Claude Code, Codex, Gemini CLI and OpenCode session logs, and writes
|
||||
it into the working tree as a file the README can reference.
|
||||
|
||||
Follow the skill for the full workflow, including the confirmation required before the first
|
||||
|
||||
@@ -359,6 +359,7 @@
|
||||
],
|
||||
"rules": ["common"],
|
||||
"skills": [
|
||||
"rails-patterns",
|
||||
"tdd-workflow",
|
||||
"verification-loop"
|
||||
],
|
||||
|
||||
@@ -1,146 +0,0 @@
|
||||
# Architecture Improvement Recommendations
|
||||
|
||||
This document captures architect-level improvements for the Everything Claude Code (ECC) project. It is written from the perspective of a Claude Code coding architect aiming to improve maintainability, consistency, and long-term quality.
|
||||
|
||||
---
|
||||
|
||||
## 1. Documentation and Single Source of Truth
|
||||
|
||||
### 1.1 Agent / Command / Skill Count Sync
|
||||
|
||||
**Issue:** AGENTS.md states "13 specialized agents, 50+ skills, 33 commands" while the repo has **16 agents**, **65+ skills**, and **40 commands**. README and other docs also vary. This causes confusion for contributors and users.
|
||||
|
||||
**Recommendation:**
|
||||
|
||||
- **Single source of truth:** Derive counts (and optionally tables) from the filesystem or a small manifest. Options:
|
||||
- **Option A:** Add a script (e.g. `scripts/ci/catalog.js`) that scans `agents/*.md`, `commands/*.md`, and `skills/*/SKILL.md` and outputs JSON/Markdown. CI and docs can consume this.
|
||||
- **Option B:** Maintain one `docs/catalog.json` (or YAML) that lists agents, commands, and skills with metadata; scripts and docs read from it. Requires discipline to update on add/remove.
|
||||
- **Short-term:** Manually sync AGENTS.md, README.md, and CLAUDE.md with actual counts and list any new agents (e.g. chief-of-staff, loop-operator, harness-optimizer) in the agent table.
|
||||
|
||||
**Impact:** High — affects first impression and contributor trust.
|
||||
|
||||
---
|
||||
|
||||
### 1.2 Command → Agent / Skill Map
|
||||
|
||||
**Issue:** There is no single machine- or human-readable map of "which command uses which agent(s) or skill(s)." This lives in README tables and individual command `.md` files, which can drift.
|
||||
|
||||
**Recommendation:**
|
||||
|
||||
- Add a **command registry** (e.g. in `docs/` or as frontmatter in command files) that lists for each command: name, description, primary agent(s), skills referenced. Can be generated from command file content or maintained by hand.
|
||||
- Expose a "map" in docs (e.g. `docs/COMMAND-AGENT-MAP.md`) or in the generated catalog for discoverability and for tooling (e.g. "which commands use tdd-guide?").
|
||||
|
||||
**Impact:** Medium — improves discoverability and refactoring safety.
|
||||
|
||||
---
|
||||
|
||||
## 2. Testing and Quality
|
||||
|
||||
### 2.1 Test Discovery vs Hardcoded List
|
||||
|
||||
**Issue:** `tests/run-all.js` uses a **hardcoded list** of test files. New test files are not run unless someone updates `run-all.js`, so coverage can be incomplete by omission.
|
||||
|
||||
**Recommendation:**
|
||||
|
||||
- **Glob-based discovery:** Discover test files by pattern (e.g. `**/*.test.js` under `tests/`) and run them, with an optional allowlist/denylist for special cases. This makes new tests automatically part of the suite.
|
||||
- Keep a single entry point (`tests/run-all.js`) that runs discovered tests and aggregates results.
|
||||
|
||||
**Impact:** High — prevents regression where new tests exist but are never executed.
|
||||
|
||||
---
|
||||
|
||||
### 2.2 Test Coverage Metrics
|
||||
|
||||
**Issue:** There is no coverage tool (e.g. nyc/c8/istanbul). The project cannot assert "80%+ coverage" for its own scripts; coverage is implicit.
|
||||
|
||||
**Recommendation:**
|
||||
|
||||
- Introduce a coverage tool for Node scripts (e.g. `c8` or `nyc`) and run it in CI. Start with a baseline (e.g. 60%) and raise over time; or at least report coverage in CI without failing so the team can see trends.
|
||||
- Focus on `scripts/` (lib + hooks + ci) as the primary target; exclude one-off scripts if needed.
|
||||
|
||||
**Impact:** Medium — aligns the project with its own AGENTS.md guidance (80%+ coverage) and surfaces untested paths.
|
||||
|
||||
---
|
||||
|
||||
## 3. Schema and Validation
|
||||
|
||||
### 3.1 Use Hooks JSON Schema in CI
|
||||
|
||||
**Issue:** `schemas/hooks.schema.json` exists and defines the hook configuration shape, but `scripts/ci/validate-hooks.js` does **not** use it. Validation is duplicated (VALID_EVENTS, structure) and can drift from the schema.
|
||||
|
||||
**Recommendation:**
|
||||
|
||||
- Use a JSON Schema validator (e.g. `ajv`) in `validate-hooks.js` to validate `hooks/hooks.json` against `schemas/hooks.schema.json`. Keep the validator as the single source of truth for structure; retain only hook-specific checks (e.g. inline JS syntax) in the script.
|
||||
- Ensures schema and validator stay in sync and allows IDE/editor validation via `$schema` in hooks.json.
|
||||
|
||||
**Impact:** Medium — reduces drift and improves contributor experience when editing hooks.
|
||||
|
||||
---
|
||||
|
||||
## 4. Cross-Harness and i18n
|
||||
|
||||
### 4.1 Skill/Agent Subset Sync (.agents/skills, .cursor/skills)
|
||||
|
||||
**Issue:** `.agents/skills/` (Codex) and `.cursor/skills/` are subsets of `skills/`. Adding or removing a skill in the main repo requires manually updating these subsets, which can be forgotten.
|
||||
|
||||
**Recommendation:**
|
||||
|
||||
- Document in CONTRIBUTING.md that adding a skill may require updating `.agents/skills` and `.cursor/skills` (and how to do it).
|
||||
- Optionally: a CI check or script that compares `skills/` to the subsets and fails or warns if a skill is in one set but not the other when it should be (e.g. by convention or by a small manifest).
|
||||
|
||||
**Impact:** Low–Medium — reduces cross-harness drift.
|
||||
|
||||
---
|
||||
|
||||
### 4.2 Translation Drift (docs/ zh-CN, zh-TW, ja-JP)
|
||||
|
||||
**Issue:** Translations in `docs/` duplicate agents, commands, skills. As the English source evolves, translations can become outdated without clear process or tooling.
|
||||
|
||||
**Recommendation:**
|
||||
|
||||
- Document a **translation process:** when to update (e.g. on release), who owns each locale, and how to detect stale content (e.g. diff file lists or key sections).
|
||||
- Consider: translation status file (e.g. `docs/i18n-status.md`) or CI that checks translation file existence/timestamps and warns if English was updated more recently than a translation.
|
||||
- Long-term: consider extraction/placeholder format (e.g. i18n keys) so translations reference the same structure as the English source.
|
||||
|
||||
**Impact:** Medium — improves experience for non-English users and reduces confusion from outdated translations.
|
||||
|
||||
---
|
||||
|
||||
## 5. Hooks and Scripts
|
||||
|
||||
### 5.1 Hook Runtime Consistency
|
||||
|
||||
**Issue:** Hooks should keep a consistent Node-mode dispatch surface. Continuous-learning observation now dispatches through `run-with-flags.js` and `observe-runner.js`, which delegates to the existing `observe.sh` implementation without exposing a shell-mode hook entry.
|
||||
|
||||
**Recommendation:**
|
||||
|
||||
- Prefer Node for new hooks when possible (cross-platform, single runtime). If shell is required, document why and keep the surface small.
|
||||
- Ensure `ECC_HOOK_PROFILE` and `ECC_DISABLED_HOOKS` are respected in all code paths (including shell) so behavior is consistent.
|
||||
|
||||
**Impact:** Low — maintains current design; improves if more hooks migrate to Node.
|
||||
|
||||
---
|
||||
|
||||
## 6. Summary Table
|
||||
|
||||
| Area | Improvement | Priority | Effort |
|
||||
|-------------------|--------------------------------------|----------|---------|
|
||||
| Doc sync | Sync AGENTS.md/README counts & table | High | Low |
|
||||
| Single source | Catalog script or manifest | High | Medium |
|
||||
| Test discovery | Glob-based test runner | High | Low |
|
||||
| Coverage | Add c8/nyc and CI coverage | Medium | Medium |
|
||||
| Hook schema in CI | Validate hooks.json via schema | Medium | Low |
|
||||
| Command map | Command → agent/skill registry | Medium | Medium |
|
||||
| Subset sync | Document/CI for .agents/.cursor | Low–Med | Low–Med |
|
||||
| Translations | Process + stale detection | Medium | Medium |
|
||||
| Hook runtime | Prefer Node; document shell use | Low | Low |
|
||||
|
||||
---
|
||||
|
||||
## 7. Quick Wins (Immediate)
|
||||
|
||||
1. **Update AGENTS.md:** Set agent count to 16; add chief-of-staff, loop-operator, harness-optimizer to the agent table; align skill/command counts with repo.
|
||||
2. **Test discovery:** Change `run-all.js` to discover `**/*.test.js` under `tests/` (with optional allowlist) so new tests are always run.
|
||||
3. **Wire hooks schema:** In `validate-hooks.js`, validate `hooks/hooks.json` against `schemas/hooks.schema.json` using ajv (or similar) and keep only hook-specific checks in the script.
|
||||
|
||||
These three can be done in one or two sessions and materially improve consistency and reliability.
|
||||
@@ -741,7 +741,7 @@
|
||||
},
|
||||
{
|
||||
"command": "prp-pr",
|
||||
"description": "Create a GitHub PR from current branch with unpushed commits — discovers templates, analyzes changes, pushes",
|
||||
"description": "Alias of /pr for the PRP workflow series. Use when creating a pull request mid-PRP workflow; otherwise use /pr.",
|
||||
"type": "testing",
|
||||
"primaryAgents": [],
|
||||
"allAgents": [],
|
||||
|
||||
@@ -1,322 +0,0 @@
|
||||
# ECC 2.0 Session Adapter Discovery
|
||||
|
||||
## Purpose
|
||||
|
||||
This document turns the March 11 ECC 2.0 control-plane direction into a
|
||||
concrete adapter and snapshot design grounded in the orchestration code that
|
||||
already exists in this repo.
|
||||
|
||||
## Current Implemented Substrate
|
||||
|
||||
The repo already has a real first-pass orchestration substrate:
|
||||
|
||||
- `scripts/lib/tmux-worktree-orchestrator.js`
|
||||
provisions tmux panes plus isolated git worktrees
|
||||
- `scripts/orchestrate-worktrees.js`
|
||||
is the current session launcher
|
||||
- `scripts/lib/orchestration-session.js`
|
||||
collects machine-readable session snapshots
|
||||
- `scripts/orchestration-status.js`
|
||||
exports those snapshots from a session name or plan file
|
||||
- `commands/sessions.md`
|
||||
already exposes adjacent session-history concepts from Claude's local store
|
||||
- `scripts/lib/session-adapters/canonical-session.js`
|
||||
defines the canonical `ecc.session.v1` normalization layer
|
||||
- `scripts/lib/session-adapters/dmux-tmux.js`
|
||||
wraps the current orchestration snapshot collector as adapter `dmux-tmux`
|
||||
- `scripts/lib/session-adapters/claude-history.js`
|
||||
normalizes Claude local session history as a second adapter
|
||||
- `scripts/lib/session-adapters/registry.js`
|
||||
selects adapters from explicit targets and target types
|
||||
- `scripts/session-inspect.js`
|
||||
emits canonical read-only session snapshots through the adapter registry
|
||||
|
||||
In practice, ECC can already answer:
|
||||
|
||||
- what workers exist in a tmux-orchestrated session
|
||||
- what pane each worker is attached to
|
||||
- what task, status, and handoff files exist for each worker
|
||||
- whether the session is active and how many panes/workers exist
|
||||
- what the most recent Claude local session looked like in the same canonical
|
||||
snapshot shape as orchestration sessions
|
||||
|
||||
That is enough to prove the substrate. It is not yet enough to qualify as a
|
||||
general ECC 2.0 control plane.
|
||||
|
||||
## What The Current Snapshot Actually Models
|
||||
|
||||
The current snapshot model coming out of `scripts/lib/orchestration-session.js`
|
||||
has these effective fields:
|
||||
|
||||
```json
|
||||
{
|
||||
"sessionName": "workflow-visual-proof",
|
||||
"coordinationDir": ".../.claude/orchestration/workflow-visual-proof",
|
||||
"repoRoot": "...",
|
||||
"targetType": "plan",
|
||||
"sessionActive": true,
|
||||
"paneCount": 2,
|
||||
"workerCount": 2,
|
||||
"workerStates": {
|
||||
"running": 1,
|
||||
"completed": 1
|
||||
},
|
||||
"panes": [
|
||||
{
|
||||
"paneId": "%95",
|
||||
"windowIndex": 1,
|
||||
"paneIndex": 0,
|
||||
"title": "seed-check",
|
||||
"currentCommand": "codex",
|
||||
"currentPath": "/tmp/worktree",
|
||||
"active": false,
|
||||
"dead": false,
|
||||
"pid": 1234
|
||||
}
|
||||
],
|
||||
"workers": [
|
||||
{
|
||||
"workerSlug": "seed-check",
|
||||
"workerDir": ".../seed-check",
|
||||
"status": {
|
||||
"state": "running",
|
||||
"updated": "...",
|
||||
"branch": "...",
|
||||
"worktree": "...",
|
||||
"taskFile": "...",
|
||||
"handoffFile": "..."
|
||||
},
|
||||
"task": {
|
||||
"objective": "...",
|
||||
"seedPaths": ["scripts/orchestrate-worktrees.js"]
|
||||
},
|
||||
"handoff": {
|
||||
"summary": [],
|
||||
"validation": [],
|
||||
"remainingRisks": []
|
||||
},
|
||||
"files": {
|
||||
"status": ".../status.md",
|
||||
"task": ".../task.md",
|
||||
"handoff": ".../handoff.md"
|
||||
},
|
||||
"pane": {
|
||||
"paneId": "%95",
|
||||
"title": "seed-check"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
This is already a useful operator payload. The main limitation is that it is
|
||||
implicitly tied to one execution style:
|
||||
|
||||
- tmux pane identity
|
||||
- worker slug equals pane title
|
||||
- markdown coordination files
|
||||
- plan-file or session-name lookup rules
|
||||
|
||||
## Gap Between ECC 1.x And ECC 2.0
|
||||
|
||||
ECC 1.x currently has two different "session" surfaces:
|
||||
|
||||
1. Claude local session history
|
||||
2. Orchestration runtime/session snapshots
|
||||
|
||||
Those surfaces are adjacent but not unified.
|
||||
|
||||
The missing ECC 2.0 layer is a harness-neutral session adapter boundary that
|
||||
can normalize:
|
||||
|
||||
- tmux-orchestrated workers
|
||||
- plain Claude sessions
|
||||
- Codex worktree sessions
|
||||
- OpenCode sessions
|
||||
- future GitHub/App or remote-control sessions
|
||||
|
||||
Without that adapter layer, any future operator UI would be forced to read
|
||||
tmux-specific details and coordination markdown directly.
|
||||
|
||||
## Adapter Boundary
|
||||
|
||||
ECC 2.0 should introduce a canonical session adapter contract.
|
||||
|
||||
Suggested minimal interface:
|
||||
|
||||
```ts
|
||||
type SessionAdapter = {
|
||||
id: string;
|
||||
canOpen(target: SessionTarget): boolean;
|
||||
open(target: SessionTarget): Promise<AdapterHandle>;
|
||||
};
|
||||
|
||||
type AdapterHandle = {
|
||||
getSnapshot(): Promise<CanonicalSessionSnapshot>;
|
||||
streamEvents?(onEvent: (event: SessionEvent) => void): Promise<() => void>;
|
||||
runAction?(action: SessionAction): Promise<ActionResult>;
|
||||
};
|
||||
```
|
||||
|
||||
### Canonical Snapshot Shape
|
||||
|
||||
Suggested first-pass canonical payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"schemaVersion": "ecc.session.v1",
|
||||
"adapterId": "dmux-tmux",
|
||||
"session": {
|
||||
"id": "workflow-visual-proof",
|
||||
"kind": "orchestrated",
|
||||
"state": "active",
|
||||
"repoRoot": "...",
|
||||
"sourceTarget": {
|
||||
"type": "plan",
|
||||
"value": ".claude/plan/workflow-visual-proof.json"
|
||||
}
|
||||
},
|
||||
"workers": [
|
||||
{
|
||||
"id": "seed-check",
|
||||
"label": "seed-check",
|
||||
"state": "running",
|
||||
"branch": "...",
|
||||
"worktree": "...",
|
||||
"runtime": {
|
||||
"kind": "tmux-pane",
|
||||
"command": "codex",
|
||||
"pid": 1234,
|
||||
"active": false,
|
||||
"dead": false
|
||||
},
|
||||
"intent": {
|
||||
"objective": "...",
|
||||
"seedPaths": ["scripts/orchestrate-worktrees.js"]
|
||||
},
|
||||
"outputs": {
|
||||
"summary": [],
|
||||
"validation": [],
|
||||
"remainingRisks": []
|
||||
},
|
||||
"artifacts": {
|
||||
"statusFile": "...",
|
||||
"taskFile": "...",
|
||||
"handoffFile": "..."
|
||||
}
|
||||
}
|
||||
],
|
||||
"aggregates": {
|
||||
"workerCount": 2,
|
||||
"states": {
|
||||
"running": 1,
|
||||
"completed": 1
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This preserves the useful signal already present while removing tmux-specific
|
||||
details from the control-plane contract.
|
||||
|
||||
## First Adapters To Support
|
||||
|
||||
### 1. `dmux-tmux`
|
||||
|
||||
Wrap the logic already living in
|
||||
`scripts/lib/orchestration-session.js`.
|
||||
|
||||
This is the easiest first adapter because the substrate is already real.
|
||||
|
||||
### 2. `claude-history`
|
||||
|
||||
Normalize the data that
|
||||
`commands/sessions.md`
|
||||
and the existing session-manager utilities already expose:
|
||||
|
||||
- session id / alias
|
||||
- branch
|
||||
- worktree
|
||||
- project path
|
||||
- recency / file size / item counts
|
||||
|
||||
This provides a non-orchestrated baseline for ECC 2.0.
|
||||
|
||||
### 3. `codex-worktree`
|
||||
|
||||
Use the same canonical shape, but back it with Codex-native execution metadata
|
||||
instead of tmux assumptions where available.
|
||||
|
||||
### 4. `opencode`
|
||||
|
||||
Use the same adapter boundary once OpenCode session metadata is stable enough to
|
||||
normalize.
|
||||
|
||||
## What Should Stay Out Of The Adapter Layer
|
||||
|
||||
The adapter layer should not own:
|
||||
|
||||
- business logic for merge sequencing
|
||||
- operator UI layout
|
||||
- pricing or monetization decisions
|
||||
- install profile selection
|
||||
- tmux lifecycle orchestration itself
|
||||
|
||||
Its job is narrower:
|
||||
|
||||
- detect session targets
|
||||
- load normalized snapshots
|
||||
- optionally stream runtime events
|
||||
- optionally expose safe actions
|
||||
|
||||
## Current File Layout
|
||||
|
||||
The adapter layer now lives in:
|
||||
|
||||
```text
|
||||
scripts/lib/session-adapters/
|
||||
canonical-session.js
|
||||
dmux-tmux.js
|
||||
claude-history.js
|
||||
registry.js
|
||||
scripts/session-inspect.js
|
||||
tests/lib/session-adapters.test.js
|
||||
tests/scripts/session-inspect.test.js
|
||||
```
|
||||
|
||||
The current orchestration snapshot parser is now being consumed as an adapter
|
||||
implementation rather than remaining the only product contract.
|
||||
|
||||
## Immediate Next Steps
|
||||
|
||||
1. Add a third adapter, likely `codex-worktree`, so the abstraction moves
|
||||
beyond tmux plus Claude-history.
|
||||
2. Decide whether canonical snapshots need separate `state` and `health`
|
||||
fields before UI work starts.
|
||||
3. Decide whether event streaming belongs in v1 or stays out until after the
|
||||
snapshot layer proves itself.
|
||||
4. Build operator-facing panels only on top of the adapter registry, not by
|
||||
reading orchestration internals directly.
|
||||
|
||||
## Open Questions
|
||||
|
||||
1. Should worker identity be keyed by worker slug, branch, or stable UUID?
|
||||
2. Do we need separate `state` and `health` fields at the canonical layer?
|
||||
3. Should event streaming be part of v1, or should ECC 2.0 ship snapshot-only
|
||||
first?
|
||||
4. How much path information should be redacted before snapshots leave the local
|
||||
machine?
|
||||
5. Should the adapter registry live inside this repo long-term, or move into the
|
||||
eventual ECC 2.0 control-plane app once the interface stabilizes?
|
||||
|
||||
## Recommendation
|
||||
|
||||
Treat the current tmux/worktree implementation as adapter `0`, not as the final
|
||||
product surface.
|
||||
|
||||
The shortest path to ECC 2.0 is:
|
||||
|
||||
1. preserve the current orchestration substrate
|
||||
2. wrap it in a canonical session adapter contract
|
||||
3. add one non-tmux adapter
|
||||
4. only then start building operator panels on top
|
||||
@@ -46,7 +46,7 @@ That means the shortest safe path is:
|
||||
Use the current workspace split consistently:
|
||||
|
||||
- live code work happens in cloned repos under `~/GitHub`
|
||||
- repo-specific active execution context lives in repo-level `WORKING-CONTEXT.md`
|
||||
- repo-specific direction lives in the repo's planning docs under `docs/`, shipped change history in `CHANGELOG.md`
|
||||
- broader non-code context can live in KB/archive layers
|
||||
- durable cross-machine truth should prefer GitHub, Linear, and the knowledge base
|
||||
|
||||
@@ -105,7 +105,7 @@ Source examples:
|
||||
Translate into:
|
||||
|
||||
- `knowledge-ops`
|
||||
- repo `WORKING-CONTEXT.md`
|
||||
- repo planning docs under `docs/` and `CHANGELOG.md`
|
||||
- GitHub / Linear / KB-backed durable context
|
||||
- future deep memory work under `#1049`
|
||||
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
# ECC and the Ito desk
|
||||
|
||||
ECC is the public agentic-engineering toolkit; the Ito desk is Affaan's
|
||||
private ops system. The connection surface in this repo is the set of
|
||||
public `ito-*` skills (`skills/ito-baskets`, `skills/ito-compute`,
|
||||
`skills/ito-inference`, `skills/ito-training`). Each of them is a thin
|
||||
pointer: it names the supported boundary and hands real work to the
|
||||
separately installed canonical CLI or MCP server. ECC itself implements no
|
||||
compute booking, inference serving, training stack or basket trading, and
|
||||
nothing here may claim those capabilities exist inside this repo.
|
||||
|
||||
Desk-side work that touches ECC runs as bounded lane tasks. The lane-worker
|
||||
doctrine (see `docs/LANE-RULES.md`) is: one worker, one task, one branch,
|
||||
one PR or one receipt; real work only, meaning code edits, tests, commits
|
||||
and a PR, with the final message as the receipt; no self-review loops, no
|
||||
receipt ledgers, no merging to main, no publishing, no deployments, no
|
||||
messages; blocked means naming exactly who or what unblocks. The doctrine
|
||||
exists because unbounded agent loops were the dominant failure mode of the
|
||||
desk's earlier automation.
|
||||
|
||||
The merge rule for anything desk-related in this repo: fixes and tests
|
||||
merge freely. Anything that adds a third-party tool, a vendor-named skill,
|
||||
or an external link waits for Affaan's explicit yes, recorded before merge.
|
||||
The living desk plan is `docs/PLAN.md` in `Ito-Markets/ito-desk`; task
|
||||
schemas and the spec book live under `docs/spec/` in the same repo. This
|
||||
file only describes the relationship; the plan repo is the source of truth.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Lane rules
|
||||
|
||||
These are the working rules for bounded lane workers (human or agent) that
|
||||
execute tasks against this repository from the Ito workstream system. They
|
||||
are copied verbatim from the lane registry
|
||||
(`lanes/RULES.md` in the Ito workstream system on the ops mini,
|
||||
2026-09-16) so a worker reading only this repo sees the same contract.
|
||||
One task, one branch, one PR or one receipt, then stop.
|
||||
|
||||
---
|
||||
|
||||
## Lane rules (every codex exec brief starts by reading this)
|
||||
You are one bounded worker. One task, one branch, one PR or one receipt, then stop.
|
||||
- Real work only: edit code, run the tests, commit, push, open the PR. No receipts about receipts, no independent review of your own output, no hashing manifests, no ledgers, no acceptance JSONs, no skill self-patching. Your final message is the receipt (under 300 words: what changed, PR link, test command and result, what is blocked and on whom).
|
||||
- Never merge to main, never publish to npm, never deploy, never send email or messages, never change Hermes profiles or launchd on the mini unless the brief says so explicitly.
|
||||
- Commits: plain messages, no Co-Authored-By or generated-with trailers, no em dashes anywhere.
|
||||
- Worktrees and caches go under ~/GitHub/ECC-worktrees or ~/GitHub on the Pro, /Volumes/Agent-Runtime/workspaces on the mini, never on the mini root disk.
|
||||
- If blocked (missing credential, approval needed, conflicting work), stop and say exactly what is needed. Do not wait, poll, or sleep.
|
||||
- Time box: finish in one pass. Do not spawn subagents.
|
||||
@@ -1,286 +0,0 @@
|
||||
# Mega Plan Repo Prompt List — March 12, 2026
|
||||
|
||||
## Purpose
|
||||
|
||||
Use these prompts to split the remaining March 11 mega-plan work by repo.
|
||||
They are written for parallel agents and assume the March 12 orchestration and
|
||||
Windows CI lane is already merged via `#417`.
|
||||
|
||||
## Current Snapshot
|
||||
|
||||
- `everything-claude-code` has finished the orchestration, Codex baseline, and
|
||||
Windows CI recovery lane.
|
||||
- The next open ECC Phase 1 items are:
|
||||
- review `#399`
|
||||
- convert recurring discussion pressure into tracked issues
|
||||
- define selective-install architecture
|
||||
- write the ECC 2.0 discovery doc
|
||||
- `agentshield`, `ECC-website`, and `skill-creator-app` all have dirty
|
||||
`main` worktrees and should not be edited directly on `main`.
|
||||
- `applications/` is not a standalone git repo. It lives inside the parent
|
||||
workspace repo at `<ECC_ROOT>`.
|
||||
|
||||
## Repo: `everything-claude-code`
|
||||
|
||||
### Prompt A — PR `#399` Review and Merge Readiness
|
||||
|
||||
```text
|
||||
Work in: <ECC_ROOT>/everything-claude-code
|
||||
|
||||
Goal:
|
||||
Review PR #399 ("fix(observe): 5-layer automated session guard to prevent
|
||||
self-loop observations") against the actual loop problem described in issue
|
||||
#398 and the March 11 mega plan. Do not assume the old failing CI on the PR is
|
||||
still meaningful, because the Windows baseline was repaired later in #417.
|
||||
|
||||
Tasks:
|
||||
1. Read issue #398 and PR #399 in full.
|
||||
2. Inspect the observe hook implementation and tests locally.
|
||||
3. Determine whether the PR really prevents observer self-observation,
|
||||
automated-session observation, and runaway recursive loops.
|
||||
4. Identify any missing env-based bypass, idle gating, or session exclusion
|
||||
behavior.
|
||||
5. Produce a merge recommendation with findings ordered by severity.
|
||||
|
||||
Constraints:
|
||||
- Do not merge automatically.
|
||||
- Do not rewrite unrelated hook behavior.
|
||||
- If you make code changes, keep them tightly scoped to observe behavior and
|
||||
tests.
|
||||
|
||||
Deliverables:
|
||||
- review summary
|
||||
- exact findings with file references
|
||||
- recommended merge / rework decision
|
||||
- test commands run
|
||||
```
|
||||
|
||||
### Prompt B — Roadmap Issues Extraction
|
||||
|
||||
```text
|
||||
Work in: <ECC_ROOT>/everything-claude-code
|
||||
|
||||
Goal:
|
||||
Convert recurring discussion pressure from the mega plan into concrete GitHub
|
||||
issues. Focus on high-signal roadmap items that unblock ECC 1.x and ECC 2.0.
|
||||
|
||||
Create issue drafts or a ready-to-post issue bundle for:
|
||||
1. selective install profiles
|
||||
2. uninstall / doctor / repair lifecycle
|
||||
3. generated skill placement and provenance policy
|
||||
4. governance past the tool call
|
||||
5. ECC 2.0 discovery doc / adapter contracts
|
||||
|
||||
Tasks:
|
||||
1. Read the March 11 mega plan and March 12 handoff.
|
||||
2. Deduplicate against already-open issues.
|
||||
3. Draft issue titles, problem statements, scope, non-goals, acceptance
|
||||
criteria, and file/system areas affected.
|
||||
|
||||
Constraints:
|
||||
- Do not create filler issues.
|
||||
- Prefer 4-6 high-value issues over a large backlog dump.
|
||||
- Keep each issue scoped so it could plausibly land in one focused PR series.
|
||||
|
||||
Deliverables:
|
||||
- issue shortlist
|
||||
- ready-to-post issue bodies
|
||||
- duplication notes against existing issues
|
||||
```
|
||||
|
||||
### Prompt C — ECC 2.0 Discovery and Adapter Spec
|
||||
|
||||
```text
|
||||
Work in: <ECC_ROOT>/everything-claude-code
|
||||
|
||||
Goal:
|
||||
Turn the existing ECC 2.0 vision into a first concrete discovery doc focused on
|
||||
adapter contracts, session/task state, token accounting, and security/policy
|
||||
events.
|
||||
|
||||
Tasks:
|
||||
1. Use the current orchestration/session snapshot code as the baseline.
|
||||
2. Define a normalized adapter contract for Claude Code, Codex, OpenCode, and
|
||||
later Cursor / GitHub App integration.
|
||||
3. Define the initial SQLite-backed data model for sessions, tasks, worktrees,
|
||||
events, findings, and approvals.
|
||||
4. Define what stays in ECC 1.x versus what belongs in ECC 2.0.
|
||||
5. Call out unresolved product decisions separately from implementation
|
||||
requirements.
|
||||
|
||||
Constraints:
|
||||
- Treat the current tmux/worktree/session snapshot substrate as the starting
|
||||
point, not a blank slate.
|
||||
- Keep the doc implementation-oriented.
|
||||
|
||||
Deliverables:
|
||||
- discovery doc
|
||||
- adapter contract sketch
|
||||
- event model sketch
|
||||
- unresolved questions list
|
||||
```
|
||||
|
||||
## Repo: `agentshield`
|
||||
|
||||
### Prompt — False Positive Audit and Regression Plan
|
||||
|
||||
```text
|
||||
Work in: <ECC_ROOT>/agentshield
|
||||
|
||||
Goal:
|
||||
Advance the AgentShield Phase 2 workstream from the mega plan: reduce false
|
||||
positives, especially where declarative deny rules, block hooks, docs examples,
|
||||
or config snippets are misclassified as executable risk.
|
||||
|
||||
Important repo state:
|
||||
- branch is currently main
|
||||
- dirty files exist in CLAUDE.md and README.md
|
||||
- classify or park existing edits before broader changes
|
||||
|
||||
Tasks:
|
||||
1. Inspect the current false-positive behavior around:
|
||||
- .claude hook configs
|
||||
- AGENTS.md / CLAUDE.md
|
||||
- .cursor rules
|
||||
- .opencode plugin configs
|
||||
- sample deny-list patterns
|
||||
2. Separate parser behavior for declarative patterns vs executable commands.
|
||||
3. Propose regression coverage additions and the exact fixture set needed.
|
||||
4. If safe after branch setup, implement the first pass of the classifier fix.
|
||||
|
||||
Constraints:
|
||||
- do not work directly on dirty main
|
||||
- keep fixes parser/classifier-scoped
|
||||
- document any remaining ambiguity explicitly
|
||||
|
||||
Deliverables:
|
||||
- branch recommendation
|
||||
- false-positive taxonomy
|
||||
- proposed or landed regression tests
|
||||
- remaining edge cases
|
||||
```
|
||||
|
||||
## Repo: `ECC-website`
|
||||
|
||||
### Prompt — Landing Rewrite and Product Framing
|
||||
|
||||
```text
|
||||
Work in: <ECC_ROOT>/ECC-website
|
||||
|
||||
Goal:
|
||||
Execute the website lane from the mega plan by rewriting the landing/product
|
||||
framing away from "config repo" and toward "open agent harness system" plus
|
||||
future control-plane direction.
|
||||
|
||||
Important repo state:
|
||||
- branch is currently main
|
||||
- dirty files exist in favicon assets and multiple page/component files
|
||||
- branch before meaningful work and preserve existing edits unless explicitly
|
||||
classified as stale
|
||||
|
||||
Tasks:
|
||||
1. Classify the dirty main worktree state.
|
||||
2. Rewrite the landing page narrative around:
|
||||
- open agent harness system
|
||||
- runtime guardrails
|
||||
- cross-harness parity
|
||||
- operator visibility and security
|
||||
3. Define or update the next key pages:
|
||||
- /skills
|
||||
- /security
|
||||
- /platforms
|
||||
- /system or /dashboard
|
||||
4. Keep the page visually intentional and product-forward, not generic SaaS.
|
||||
|
||||
Constraints:
|
||||
- do not silently overwrite existing dirty work
|
||||
- preserve existing design system where it is coherent
|
||||
- distinguish ECC 1.x toolkit from ECC 2.0 control plane clearly
|
||||
|
||||
Deliverables:
|
||||
- branch recommendation
|
||||
- landing-page rewrite diff or content spec
|
||||
- follow-up page map
|
||||
- deployment readiness notes
|
||||
```
|
||||
|
||||
## Repo: `skill-creator-app`
|
||||
|
||||
### Prompt — Skill Import Pipeline and Product Fit
|
||||
|
||||
```text
|
||||
Work in: <ECC_ROOT>/skill-creator-app
|
||||
|
||||
Goal:
|
||||
Align skill-creator-app with the mega-plan external skill sourcing and audited
|
||||
import pipeline workstream.
|
||||
|
||||
Important repo state:
|
||||
- branch is currently main
|
||||
- dirty files exist in README.md and src/lib/github.ts
|
||||
- classify or park existing changes before broader work
|
||||
|
||||
Tasks:
|
||||
1. Assess whether the app should support:
|
||||
- inventorying external skills
|
||||
- provenance tagging
|
||||
- dependency/risk audit fields
|
||||
- ECC convention adaptation workflows
|
||||
2. Review the existing GitHub integration surface in src/lib/github.ts.
|
||||
3. Produce a concrete product/technical scope for an audited import pipeline.
|
||||
4. If safe after branching, land the smallest enabling changes for metadata
|
||||
capture or GitHub ingestion.
|
||||
|
||||
Constraints:
|
||||
- do not turn this into a generic prompt-builder
|
||||
- keep the focus on audited skill ingestion and ECC-compatible output
|
||||
|
||||
Deliverables:
|
||||
- product-fit summary
|
||||
- recommended scope for v1
|
||||
- data fields / workflow steps for the import pipeline
|
||||
- code changes if they are small and clearly justified
|
||||
```
|
||||
|
||||
## Repo: `ECC` Workspace (`applications/`, `knowledge/`, `tasks/`)
|
||||
|
||||
### Prompt — Example Apps and Workflow Reliability Proofs
|
||||
|
||||
```text
|
||||
Work in: <ECC_ROOT>
|
||||
|
||||
Goal:
|
||||
Use the parent ECC workspace to support the mega-plan hosted/workflow lanes.
|
||||
This is not a standalone applications repo; it is the umbrella workspace that
|
||||
contains applications/, knowledge/, tasks/, and related planning assets.
|
||||
|
||||
Tasks:
|
||||
1. Inventory what in applications/ is real product code vs placeholder.
|
||||
2. Identify where example repos or demo apps should live for:
|
||||
- GitHub App workflow proofs
|
||||
- ECC 2.0 prototype spikes
|
||||
- example install / setup reliability checks
|
||||
3. Propose a clean workspace structure so product code, research, and planning
|
||||
stop bleeding into each other.
|
||||
4. Recommend which proof-of-concept should be built first.
|
||||
|
||||
Constraints:
|
||||
- do not move large directories blindly
|
||||
- distinguish repo structure recommendations from immediate code changes
|
||||
- keep recommendations compatible with the current multi-repo ECC setup
|
||||
|
||||
Deliverables:
|
||||
- workspace inventory
|
||||
- proposed structure
|
||||
- first demo/app recommendation
|
||||
- follow-up branch/worktree plan
|
||||
```
|
||||
|
||||
## Local Continuation
|
||||
|
||||
The current worktree should stay on ECC-native Phase 1 work that does not touch
|
||||
the existing dirty skill-file changes here. The best next local tasks are:
|
||||
|
||||
1. selective-install architecture
|
||||
2. ECC 2.0 discovery doc
|
||||
3. PR `#399` review
|
||||
@@ -1,272 +0,0 @@
|
||||
# Phase 1 Issue Bundle — March 12, 2026
|
||||
|
||||
## Status
|
||||
|
||||
These issue drafts were prepared from the March 11 mega plan plus the March 12
|
||||
handoff. I attempted to open them directly in GitHub, but issue creation was
|
||||
blocked by missing GitHub authentication in the MCP session.
|
||||
|
||||
## GitHub Status
|
||||
|
||||
These drafts were later posted via `gh`:
|
||||
|
||||
- `#423` Implement manifest-driven selective install profiles for ECC
|
||||
- `#421` Add ECC install-state plus uninstall / doctor / repair lifecycle
|
||||
- `#424` Define canonical session adapter contract for ECC 2.0 control plane
|
||||
- `#422` Define generated skill placement and provenance policy
|
||||
- `#425` Define governance and visibility past the tool call
|
||||
|
||||
The bodies below are preserved as the local source bundle used to create the
|
||||
issues.
|
||||
|
||||
## Issue 1
|
||||
|
||||
### Title
|
||||
|
||||
Implement manifest-driven selective install profiles for ECC
|
||||
|
||||
### Labels
|
||||
|
||||
- `enhancement`
|
||||
|
||||
### Body
|
||||
|
||||
```md
|
||||
## Problem
|
||||
|
||||
ECC still installs primarily by target and language. The repo now has first-pass
|
||||
selective-install manifests and a non-mutating plan resolver, but the installer
|
||||
itself does not yet consume those profiles.
|
||||
|
||||
Current groundwork already landed in-repo:
|
||||
|
||||
- `manifests/install-modules.json`
|
||||
- `manifests/install-profiles.json`
|
||||
- `scripts/ci/validate-install-manifests.js`
|
||||
- `scripts/lib/install-manifests.js`
|
||||
- `scripts/install-plan.js`
|
||||
|
||||
That means the missing step is no longer design discovery. The missing step is
|
||||
execution: wire profile/module resolution into the actual install flow while
|
||||
preserving backward compatibility.
|
||||
|
||||
## Scope
|
||||
|
||||
Implement manifest-driven install execution for current ECC targets:
|
||||
|
||||
- `claude`
|
||||
- `cursor`
|
||||
- `antigravity`
|
||||
|
||||
Add first-pass support for:
|
||||
|
||||
- `ecc-install --profile <name>`
|
||||
- `ecc-install --modules <id,id,...>`
|
||||
- target-aware filtering based on module target support
|
||||
- backward-compatible legacy language installs during rollout
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Full uninstall/doctor/repair lifecycle in the same issue
|
||||
- Codex/OpenCode install targets in the first pass if that blocks rollout
|
||||
- Reorganizing the repository into separate published packages
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- `install.sh` can resolve and install a named profile
|
||||
- `install.sh` can resolve explicit module IDs
|
||||
- Unsupported modules for a target are skipped or rejected deterministically
|
||||
- Legacy language-based install mode still works
|
||||
- Tests cover profile resolution and installer behavior
|
||||
- Docs explain the new preferred profile/module install path
|
||||
```
|
||||
|
||||
## Issue 2
|
||||
|
||||
### Title
|
||||
|
||||
Add ECC install-state plus uninstall / doctor / repair lifecycle
|
||||
|
||||
### Labels
|
||||
|
||||
- `enhancement`
|
||||
|
||||
### Body
|
||||
|
||||
```md
|
||||
## Problem
|
||||
|
||||
ECC has no canonical installed-state record. That makes uninstall, repair, and
|
||||
post-install inspection nondeterministic.
|
||||
|
||||
Today the repo can classify installable content, but it still cannot reliably
|
||||
answer:
|
||||
|
||||
- what profile/modules were installed
|
||||
- what target they were installed into
|
||||
- what paths ECC owns
|
||||
- how to remove or repair only ECC-managed files
|
||||
|
||||
Without install-state, lifecycle commands are guesswork.
|
||||
|
||||
## Scope
|
||||
|
||||
Introduce a durable install-state contract and the first lifecycle commands:
|
||||
|
||||
- `ecc list-installed`
|
||||
- `ecc uninstall`
|
||||
- `ecc doctor`
|
||||
- `ecc repair`
|
||||
|
||||
Suggested state locations:
|
||||
|
||||
- Claude: `~/.claude/ecc/install-state.json`
|
||||
- Cursor: `./.cursor/ecc-install-state.json`
|
||||
- Antigravity: `./.agent/ecc-install-state.json`
|
||||
|
||||
The state file should capture at minimum:
|
||||
|
||||
- installed version
|
||||
- timestamp
|
||||
- target
|
||||
- profile
|
||||
- resolved modules
|
||||
- copied/managed paths
|
||||
- source repo version or package version
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Rebuilding the installer architecture from scratch
|
||||
- Full remote/cloud control-plane functionality
|
||||
- Target support expansion beyond the current local installers unless it falls
|
||||
out naturally
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Successful installs write install-state deterministically
|
||||
- `list-installed` reports target/profile/modules/version cleanly
|
||||
- `doctor` reports missing or drifted managed paths
|
||||
- `repair` restores missing managed files from recorded install-state
|
||||
- `uninstall` removes only ECC-managed files and leaves unrelated local files
|
||||
alone
|
||||
- Tests cover install-state creation and lifecycle behavior
|
||||
```
|
||||
|
||||
## Issue 3
|
||||
|
||||
### Title
|
||||
|
||||
Define canonical session adapter contract for ECC 2.0 control plane
|
||||
|
||||
### Labels
|
||||
|
||||
- `enhancement`
|
||||
|
||||
### Body
|
||||
|
||||
```md
|
||||
## Problem
|
||||
|
||||
ECC now has real orchestration/session substrate, but it is still
|
||||
implementation-specific.
|
||||
|
||||
Current state:
|
||||
|
||||
- tmux/worktree orchestration exists
|
||||
- machine-readable session snapshots exist
|
||||
- Claude local session-history commands exist
|
||||
|
||||
What does not exist yet is a harness-neutral adapter boundary that can normalize
|
||||
session/task state across:
|
||||
|
||||
- tmux-orchestrated workers
|
||||
- plain Claude sessions
|
||||
- Codex worktrees
|
||||
- OpenCode sessions
|
||||
- later remote or GitHub-integrated operator surfaces
|
||||
|
||||
Without that adapter contract, any future ECC 2.0 operator shell will be forced
|
||||
to read tmux-specific and markdown-coordination details directly.
|
||||
|
||||
## Scope
|
||||
|
||||
Define and implement the first-pass canonical session adapter layer.
|
||||
|
||||
Suggested deliverables:
|
||||
|
||||
- adapter registry
|
||||
- canonical session snapshot schema
|
||||
- `dmux-tmux` adapter backed by current orchestration code
|
||||
- `claude-history` adapter backed by current session history utilities
|
||||
- read-only inspection CLI for canonical session snapshots
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Full ECC 2.0 UI in the same issue
|
||||
- Monetization/GitHub App implementation
|
||||
- Remote multi-user control plane
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- There is a documented canonical snapshot contract
|
||||
- Current tmux orchestration snapshot code is wrapped as an adapter rather than
|
||||
the top-level product contract
|
||||
- A second non-tmux adapter exists to prove the abstraction is real
|
||||
- Tests cover adapter selection and normalized snapshot output
|
||||
- The design clearly separates adapter concerns from orchestration and UI
|
||||
concerns
|
||||
```
|
||||
|
||||
## Issue 4
|
||||
|
||||
### Title
|
||||
|
||||
Define generated skill placement and provenance policy
|
||||
|
||||
### Labels
|
||||
|
||||
- `enhancement`
|
||||
|
||||
### Body
|
||||
|
||||
```md
|
||||
## Problem
|
||||
|
||||
ECC now has a large and growing skill surface, but generated/imported/learned
|
||||
skills do not yet have a clear long-term placement and provenance policy.
|
||||
|
||||
This creates several problems:
|
||||
|
||||
- unclear separation between curated skills and generated/learned skills
|
||||
- validator noise around directories that may or may not exist locally
|
||||
- weak provenance for imported or machine-generated skill content
|
||||
- uncertainty about where future automated learning outputs should live
|
||||
|
||||
As ECC grows, the repo needs explicit rules for where generated skill artifacts
|
||||
belong and how they are identified.
|
||||
|
||||
## Scope
|
||||
|
||||
Define a repo-wide policy for:
|
||||
|
||||
- curated vs generated vs imported skill placement
|
||||
- provenance metadata requirements
|
||||
- validator behavior for optional/generated skill directories
|
||||
- whether generated skills are shipped, ignored, or materialized during
|
||||
install/build steps
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Building a full external skill marketplace
|
||||
- Rewriting all existing skill content in one pass
|
||||
- Solving every content-quality issue in the same issue
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- A documented placement policy exists for generated/imported skills
|
||||
- Provenance requirements are explicit
|
||||
- Validators no longer produce ambiguous behavior around optional/generated
|
||||
skill locations
|
||||
- The policy clearly states what is publishable vs local-only
|
||||
- Follow-on implementation work is split into concrete, bounded PR-sized steps
|
||||
```
|
||||
@@ -1,59 +0,0 @@
|
||||
# PR 399 Review — March 12, 2026
|
||||
|
||||
## Scope
|
||||
|
||||
Reviewed `#399`:
|
||||
|
||||
- title: `fix(observe): 5-layer automated session guard to prevent self-loop observations`
|
||||
- head: `e7df0e588ceecfcd1072ef616034ccd33bb0f251`
|
||||
- files changed:
|
||||
- `skills/continuous-learning-v2/hooks/observe.sh`
|
||||
- `skills/continuous-learning-v2/agents/observer-loop.sh`
|
||||
|
||||
## Findings
|
||||
|
||||
### Medium
|
||||
|
||||
1. `skills/continuous-learning-v2/hooks/observe.sh`
|
||||
|
||||
The new `CLAUDE_CODE_ENTRYPOINT` guard uses a finite allowlist of known
|
||||
non-`cli` values (`sdk-ts`, `sdk-py`, `sdk-cli`, `mcp`, `remote`).
|
||||
|
||||
That leaves a forward-compatibility hole: any future non-`cli` entrypoint value
|
||||
will fall through and be treated as interactive. That reintroduces the exact
|
||||
class of automated-session observation the PR is trying to prevent.
|
||||
|
||||
The safer rule is:
|
||||
|
||||
- allow only `cli`
|
||||
- treat every other explicit entrypoint as automated
|
||||
- keep the default fallback as `cli` when the variable is unset
|
||||
|
||||
Suggested shape:
|
||||
|
||||
```bash
|
||||
case "${CLAUDE_CODE_ENTRYPOINT:-cli}" in
|
||||
cli) ;;
|
||||
*) exit 0 ;;
|
||||
esac
|
||||
```
|
||||
|
||||
## Merge Recommendation
|
||||
|
||||
`Needs one follow-up change before merge.`
|
||||
|
||||
The PR direction is correct:
|
||||
|
||||
- it closes the ECC self-observation loop in `observer-loop.sh`
|
||||
- it adds multiple guard layers in the right area of `observe.sh`
|
||||
- it already addressed the cheaper-first ordering and skip-path trimming issues
|
||||
|
||||
But the entrypoint guard should be generalized before merge so the automation
|
||||
filter does not silently age out when Claude Code introduces additional
|
||||
non-interactive entrypoints.
|
||||
|
||||
## Residual Risk
|
||||
|
||||
- There is still no dedicated regression test coverage around the new shell
|
||||
guard behavior, so the final merge should include at least one executable
|
||||
verification pass for the entrypoint and skip-path cases.
|
||||
@@ -1,355 +0,0 @@
|
||||
# PR Review And Queue Triage — March 13, 2026
|
||||
|
||||
## Snapshot
|
||||
|
||||
This document records a live GitHub triage snapshot for the
|
||||
`everything-claude-code` pull-request queue as of `2026-03-13T08:33:31Z`.
|
||||
|
||||
Sources used:
|
||||
|
||||
- `gh pr view`
|
||||
- `gh pr checks`
|
||||
- `gh pr diff --name-only`
|
||||
- targeted local verification against the merged `#399` head
|
||||
|
||||
Stale threshold used for this pass:
|
||||
|
||||
- `last updated before 2026-02-11` (`>30` days before March 13, 2026)
|
||||
|
||||
## PR `#399` Retrospective Review
|
||||
|
||||
PR:
|
||||
|
||||
- `#399` — `fix(observe): 5-layer automated session guard to prevent self-loop observations`
|
||||
- state: `MERGED`
|
||||
- merged at: `2026-03-13T06:40:03Z`
|
||||
- merge commit: `c52a28ace9e7e84c00309fc7b629955dfc46ecf9`
|
||||
|
||||
Files changed:
|
||||
|
||||
- `skills/continuous-learning-v2/hooks/observe.sh`
|
||||
- `skills/continuous-learning-v2/agents/observer-loop.sh`
|
||||
|
||||
Validation performed against merged head `546628182200c16cc222b97673ddd79e942eacce`:
|
||||
|
||||
- `bash -n` on both changed shell scripts
|
||||
- `node tests/hooks/hooks.test.js` (`204` passed, `0` failed)
|
||||
- targeted hook invocations for:
|
||||
- interactive CLI session
|
||||
- `CLAUDE_CODE_ENTRYPOINT=mcp`
|
||||
- `ECC_HOOK_PROFILE=minimal`
|
||||
- `ECC_SKIP_OBSERVE=1`
|
||||
- `agent_id` payload
|
||||
- trimmed `ECC_OBSERVE_SKIP_PATHS`
|
||||
|
||||
Behavioral result:
|
||||
|
||||
- the core self-loop fix works
|
||||
- automated-session guard branches suppress observation writes as intended
|
||||
- the final `non-cli => exit` entrypoint logic is the correct fail-closed shape
|
||||
|
||||
Remaining findings:
|
||||
|
||||
1. Medium: skipped automated sessions still create homunculus project state
|
||||
before the new guards exit.
|
||||
`observe.sh` resolves `cwd` and sources project detection before reaching the
|
||||
automated-session guard block, so `detect-project.sh` still creates
|
||||
`projects/<id>/...` directories and updates `projects.json` for sessions that
|
||||
later exit early.
|
||||
2. Low: the new guard matrix shipped without direct regression coverage.
|
||||
The hook test suite still validates adjacent behavior, but it does not
|
||||
directly assert the new `CLAUDE_CODE_ENTRYPOINT`, `ECC_HOOK_PROFILE`,
|
||||
`ECC_SKIP_OBSERVE`, `agent_id`, or trimmed skip-path branches.
|
||||
|
||||
Verdict:
|
||||
|
||||
- `#399` is technically correct for its primary goal and was safe to merge as
|
||||
the urgent loop-stop fix.
|
||||
- It still warrants a follow-up issue or patch to move automated-session guards
|
||||
ahead of project-registration side effects and to add explicit guard-path
|
||||
tests.
|
||||
|
||||
## Open PR Inventory
|
||||
|
||||
There are currently `4` open PRs.
|
||||
|
||||
### Queue Table
|
||||
|
||||
| PR | Title | Draft | Mergeable | Merge State | Updated | Stale | Current Verdict |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| `#292` | `chore(config): governance and config foundation (PR #272 split 1/6)` | `false` | `MERGEABLE` | `UNSTABLE` | `2026-03-13T07:26:55Z` | `No` | `Best current merge candidate` |
|
||||
| `#298` | `feat(agents,skills,rules): add Rust, Java, mobile, DevOps, and performance content` | `false` | `CONFLICTING` | `DIRTY` | `2026-03-11T04:29:07Z` | `No` | `Needs changes before review can finish` |
|
||||
| `#336` | `Customisation for Codex CLI - Features from Claude Code and OpenCode` | `true` | `MERGEABLE` | `UNSTABLE` | `2026-03-13T07:26:12Z` | `No` | `Needs manual review and draft exit` |
|
||||
| `#420` | `feat: add laravel skills` | `true` | `MERGEABLE` | `UNSTABLE` | `2026-03-12T22:57:36Z` | `No` | `Low-risk draft, review after draft exit` |
|
||||
|
||||
No currently open PR is stale by the `>30 days since last update` rule.
|
||||
|
||||
## Per-PR Assessment
|
||||
|
||||
### `#292` — Governance / Config Foundation
|
||||
|
||||
Live state:
|
||||
|
||||
- open
|
||||
- non-draft
|
||||
- `MERGEABLE`
|
||||
- merge state `UNSTABLE`
|
||||
- visible checks:
|
||||
- `CodeRabbit` passed
|
||||
- `GitGuardian Security Checks` passed
|
||||
|
||||
Scope:
|
||||
|
||||
- `.env.example`
|
||||
- `.github/ISSUE_TEMPLATE/copilot-task.md`
|
||||
- `.github/PULL_REQUEST_TEMPLATE.md`
|
||||
- `.gitignore`
|
||||
- `.markdownlint.json`
|
||||
- `.tool-versions`
|
||||
- `VERSION`
|
||||
|
||||
Assessment:
|
||||
|
||||
- This is the cleanest merge candidate in the current queue.
|
||||
- The branch was already refreshed onto current `main`.
|
||||
- The currently visible bot feedback is minor/nit-level rather than obviously
|
||||
merge-blocking.
|
||||
- The main caution is that only external bot checks are visible right now; no
|
||||
GitHub Actions matrix run appears in the current PR checks output.
|
||||
|
||||
Current recommendation:
|
||||
|
||||
- `Mergeable after one final owner pass.`
|
||||
- If you want a conservative path, do one quick human review of the remaining
|
||||
`.env.example`, PR-template, and `.tool-versions` nitpicks before merge.
|
||||
|
||||
### `#298` — Large Multi-Domain Content Expansion
|
||||
|
||||
Live state:
|
||||
|
||||
- open
|
||||
- non-draft
|
||||
- `CONFLICTING`
|
||||
- merge state `DIRTY`
|
||||
- visible checks:
|
||||
- `CodeRabbit` passed
|
||||
- `GitGuardian Security Checks` passed
|
||||
- `cubic · AI code reviewer` passed
|
||||
|
||||
Scope:
|
||||
|
||||
- `35` files
|
||||
- large documentation and skill/rule expansion across Java, Rust, mobile,
|
||||
DevOps, performance, data, and MLOps
|
||||
|
||||
Assessment:
|
||||
|
||||
- This PR is not ready for merge.
|
||||
- It conflicts with current `main`, so it is not even mergeable at the branch
|
||||
level yet.
|
||||
- cubic identified `34` issues across `35` files in the current review.
|
||||
Those findings are substantive and technical, not just style cleanup, and
|
||||
they cover broken or misleading examples across several new skills.
|
||||
- Even without the conflict, the scope is large enough that it needs a deliberate
|
||||
content-fix pass rather than a quick merge decision.
|
||||
|
||||
Current recommendation:
|
||||
|
||||
- `Needs changes.`
|
||||
- Rebase or restack first, then resolve the substantive example-quality issues.
|
||||
- If momentum matters, split by domain rather than carrying one very large PR.
|
||||
|
||||
### `#336` — Codex CLI Customization
|
||||
|
||||
Live state:
|
||||
|
||||
- open
|
||||
- draft
|
||||
- `MERGEABLE`
|
||||
- merge state `UNSTABLE`
|
||||
- visible checks:
|
||||
- `CodeRabbit` passed
|
||||
- `GitGuardian Security Checks` passed
|
||||
|
||||
Scope:
|
||||
|
||||
- `scripts/codex-git-hooks/pre-commit`
|
||||
- `scripts/codex-git-hooks/pre-push`
|
||||
- `scripts/codex/check-codex-global-state.sh`
|
||||
- `scripts/codex/install-global-git-hooks.sh`
|
||||
- `scripts/sync-ecc-to-codex.sh`
|
||||
|
||||
Assessment:
|
||||
|
||||
- This PR is no longer conflicting, but it is still draft-only and has not had
|
||||
a meaningful first-party review pass.
|
||||
- It modifies user-global Codex setup behavior and git-hook installation, so the
|
||||
operational blast radius is higher than a docs-only PR.
|
||||
- The visible checks are only external bots; there is no full GitHub Actions run
|
||||
shown in the current check set.
|
||||
- Because the branch comes from a contributor fork `main`, it also deserves an
|
||||
extra sanity pass on what exactly is being proposed before changing status.
|
||||
|
||||
Current recommendation:
|
||||
|
||||
- `Needs changes before merge readiness`, where the required changes are process
|
||||
and review oriented rather than an already-proven code defect:
|
||||
- finish manual review
|
||||
- run or confirm validation on the global-state scripts
|
||||
- take it out of draft only after that review is complete
|
||||
|
||||
### `#420` — Laravel Skills
|
||||
|
||||
Live state:
|
||||
|
||||
- open
|
||||
- draft
|
||||
- `MERGEABLE`
|
||||
- merge state `UNSTABLE`
|
||||
- visible checks:
|
||||
- `CodeRabbit` passed
|
||||
- `GitGuardian Security Checks` passed
|
||||
|
||||
Scope:
|
||||
|
||||
- `README.md`
|
||||
- `examples/laravel-api-CLAUDE.md`
|
||||
- `rules/php/patterns.md`
|
||||
- `rules/php/security.md`
|
||||
- `rules/php/testing.md`
|
||||
- `skills/configure-ecc/SKILL.md`
|
||||
- `skills/laravel-patterns/SKILL.md`
|
||||
- `skills/laravel-security/SKILL.md`
|
||||
- `skills/laravel-tdd/SKILL.md`
|
||||
- `skills/laravel-verification/SKILL.md`
|
||||
|
||||
Assessment:
|
||||
|
||||
- This is content-heavy and operationally lower risk than `#336`.
|
||||
- It is still draft and has not had a substantive human review pass yet.
|
||||
- The visible checks are external bots only.
|
||||
- Nothing in the live PR state suggests a merge blocker yet, but it is not ready
|
||||
to be merged simply because it is still draft and under-reviewed.
|
||||
|
||||
Current recommendation:
|
||||
|
||||
- `Review next after the highest-priority non-draft work.`
|
||||
- Likely a good review candidate once the author is ready to exit draft.
|
||||
|
||||
## Mergeability Buckets
|
||||
|
||||
### Mergeable Now Or After A Final Owner Pass
|
||||
|
||||
- `#292`
|
||||
|
||||
### Needs Changes Before Merge
|
||||
|
||||
- `#298`
|
||||
- `#336`
|
||||
|
||||
### Draft / Needs Review Before Any Merge Decision
|
||||
|
||||
- `#420`
|
||||
|
||||
### Stale `>30 Days`
|
||||
|
||||
- none
|
||||
|
||||
## Recommended Order
|
||||
|
||||
1. `#292`
|
||||
This is the cleanest live merge candidate.
|
||||
2. `#420`
|
||||
Low runtime risk, but wait for draft exit and a real review pass.
|
||||
3. `#336`
|
||||
Review carefully because it changes global Codex sync and hook behavior.
|
||||
4. `#298`
|
||||
Rebase and fix the substantive content issues before spending more review time
|
||||
on it.
|
||||
|
||||
## Bottom Line
|
||||
|
||||
- `#399`: safe bugfix merge with one follow-up cleanup still warranted
|
||||
- `#292`: highest-priority merge candidate in the current open queue
|
||||
- `#298`: not mergeable; conflicts plus substantive content defects
|
||||
- `#336`: no longer conflicting, but not ready while still draft and lightly
|
||||
validated
|
||||
- `#420`: draft, low-risk content lane, review after the non-draft queue
|
||||
|
||||
## Live Refresh
|
||||
|
||||
Refreshed at `2026-03-13T22:11:40Z`.
|
||||
|
||||
### Main Branch
|
||||
|
||||
- `origin/main` is green right now, including the Windows test matrix.
|
||||
- Mainline CI repair is not the current bottleneck.
|
||||
|
||||
### Updated Queue Read
|
||||
|
||||
#### `#292` — Governance / Config Foundation
|
||||
|
||||
- open
|
||||
- non-draft
|
||||
- `MERGEABLE`
|
||||
- visible checks:
|
||||
- `CodeRabbit` passed
|
||||
- `GitGuardian Security Checks` passed
|
||||
- highest-signal remaining work is not CI repair; it is the small correctness
|
||||
pass on `.env.example` and PR-template alignment before merge
|
||||
|
||||
Current recommendation:
|
||||
|
||||
- `Next actionable PR.`
|
||||
- Either patch the remaining doc/config correctness issues, or do one final
|
||||
owner pass and merge if you accept the current tradeoffs.
|
||||
|
||||
#### `#420` — Laravel Skills
|
||||
|
||||
- open
|
||||
- draft
|
||||
- `MERGEABLE`
|
||||
- visible checks:
|
||||
- `CodeRabbit` skipped because the PR is draft
|
||||
- `GitGuardian Security Checks` passed
|
||||
- no substantive human review is visible yet
|
||||
|
||||
Current recommendation:
|
||||
|
||||
- `Review after the non-draft queue.`
|
||||
- Low implementation risk, but not merge-ready while still draft and
|
||||
under-reviewed.
|
||||
|
||||
#### `#336` — Codex CLI Customization
|
||||
|
||||
- open
|
||||
- draft
|
||||
- `MERGEABLE`
|
||||
- visible checks:
|
||||
- `CodeRabbit` passed
|
||||
- `GitGuardian Security Checks` passed
|
||||
- still needs a deliberate manual review because it touches global Codex sync
|
||||
and git-hook installation behavior
|
||||
|
||||
Current recommendation:
|
||||
|
||||
- `Manual-review lane, not immediate merge lane.`
|
||||
|
||||
#### `#298` — Large Content Expansion
|
||||
|
||||
- open
|
||||
- non-draft
|
||||
- `CONFLICTING`
|
||||
- still the hardest remaining PR in the queue
|
||||
|
||||
Current recommendation:
|
||||
|
||||
- `Last priority among current open PRs.`
|
||||
- Rebase first, then handle the substantive content/example corrections.
|
||||
|
||||
### Current Order
|
||||
|
||||
1. `#292`
|
||||
2. `#420`
|
||||
3. `#336`
|
||||
4. `#298`
|
||||
+159
@@ -0,0 +1,159 @@
|
||||
# ECC Roadmap
|
||||
|
||||
Status: maintainer planning draft, updated 2026-09-09 against the integrated
|
||||
source candidate based on release 2.2.1. Source inclusion is not a release or live
|
||||
verification claim. Dates are targets, not commitments; bracketed numbers remain
|
||||
planning choices.
|
||||
|
||||
The two older planning docs stay as evidence and history:
|
||||
`docs/ECC-2.0-GA-ROADMAP.md` (2.0 milestones and control-plane deltas) and
|
||||
`docs/ECC-PRO-SECURITY-ROADMAP.md` (AgentShield and Pro conversion). This file
|
||||
is the short, current view.
|
||||
|
||||
## Vision
|
||||
|
||||
ECC is the operating layer between a developer and whatever coding agent they
|
||||
run. Shared skills, rules, and agent guidance provide portable core workflows
|
||||
across Claude Code, Codex, OpenCode, Cursor, Gemini, and other harnesses.
|
||||
Hooks, installation paths, and feature coverage vary by host; consult the
|
||||
[support status matrix](../README.md#platform-support) for current limits.
|
||||
The bar for everything that ships: simpler to read, faster to run, and
|
||||
traceable after the fact, for agents and humans alike.
|
||||
|
||||
Three things follow from that.
|
||||
|
||||
1. **The repo is the product.** Curated skills, hooks, and rules are the
|
||||
surface people install. Anything that is not installed, tested, or read by
|
||||
someone should not be in the tree.
|
||||
2. **Evidence over assertion.** A harness change earns trust through a gate
|
||||
receipt, a capsule, and a reproducible verdict, not through a paragraph
|
||||
saying it works. The offline eval framework provides the recording and review primitives;
|
||||
isolated candidate execution remains future work.
|
||||
3. **Operator patterns travel.** Approval loops, channel discipline,
|
||||
agreement generation, and e-sign placement were built for one desk. As
|
||||
generic skills they are useful to anyone running agents next to
|
||||
counterparties, customers, or money.
|
||||
|
||||
## Where we are
|
||||
|
||||
- The 2.2.1 source baseline includes guided manifest-driven setup, install-state
|
||||
ownership, repair and uninstall. Its release workflow requires exact-head
|
||||
validation; this roadmap is not release-signature evidence.
|
||||
- Catalog in this source snapshot: 68 agents, 291 skills, 94 legacy commands. The
|
||||
count is a liability as much as an asset. Overlapping and unreferenced
|
||||
skills exist.
|
||||
- The README now has one primary install section, with per-harness details
|
||||
and release history linked to `CHANGELOG.md`. Further shortening is a target,
|
||||
not a completed claim.
|
||||
- Eval source now includes capsule journals, replay matching and offline
|
||||
receipt inspection, plus a protocol example. Candidate execution and staged
|
||||
gate runs are disabled: no actual OS containment exists. Offline validation
|
||||
and a receipt signature do not establish safe execution or promotion authority.
|
||||
- The README describes AgentShield scanning and the hosted ECC Pro surface.
|
||||
Further conversion and scan-history improvements below are proposals, not
|
||||
evidence of missing paid functionality or verified adoption.
|
||||
|
||||
## Plan
|
||||
|
||||
### Track A: condense
|
||||
|
||||
Cut what nobody reads or installs. Merge what overlaps. One README that reads
|
||||
top to bottom in one pass. Exit criteria: no zero-reference tracked doc
|
||||
outside `docs/releases/`, no deprecated skill still shipped by default,
|
||||
README under [1,200] lines with one install path per harness.
|
||||
|
||||
### Track B: evidence
|
||||
|
||||
Implement and independently test an OS executor before enabling the gate:
|
||||
contain child processes, filesystem and network access, scrub inherited
|
||||
capabilities, enforce resource limits, and bind replay and result provenance.
|
||||
Keep execution disabled until those boundaries are proven. Then wire the
|
||||
`harness-optimizer` agent and `/harness-audit` to emit gate receipts. Add
|
||||
capsule recording to the hooks that already log session activity. Then the
|
||||
next two plan slices: offline retrospective grouping over capsules (no new
|
||||
rollouts) and forced-compaction tests that prove pinned constraints survive.
|
||||
|
||||
Offline code preparation is available as `capsule group` over explicitly
|
||||
selected, verified local snapshots from one task family. It only groups recorded
|
||||
counts and digests; it does not run candidates, score outcomes or promote changes.
|
||||
This utility does not fulfill the executor, hook-recording or stable-taskset
|
||||
prerequisites for the operational milestone below. See the
|
||||
[retrospective contract](architecture/eval-harness-frameworks.md#offline-retrospective-preparation).
|
||||
|
||||
### Track C: operator skills
|
||||
|
||||
The four desk-pattern skills are present in this candidate: operator approval
|
||||
loop, counterparty channel discipline, master agreement drafting with bounded
|
||||
schedule append, and e-sign field placement guidance. Validate each with its
|
||||
actual consumer and collect outside feedback before adding more. Written send
|
||||
and audience contracts do not claim transport enforcement; generated agreements
|
||||
remain drafts and DOCX conversion does not establish execution readiness.
|
||||
|
||||
### Track D: distribution and revenue
|
||||
|
||||
Keep the release path boring: tag on main, CI green at the exact head, packed
|
||||
artifact tested on three platforms. Improve the AgentShield-to-Pro conversion path, evaluating hosted scan history
|
||||
and a PR-comment autofix loop against what the hosted product already supports. Details and
|
||||
scoring live in the security roadmap.
|
||||
|
||||
## Next 90 days
|
||||
|
||||
Window: 2026-09-02 to 2026-12-01.
|
||||
|
||||
### September
|
||||
|
||||
- Review and release the composed 2026-09-02 program: offline eval frameworks,
|
||||
desk-pattern skills, condensation and this roadmap. The source candidate
|
||||
incorporates them; merge and release remain separate maintainer decisions.
|
||||
- README linear pass merged. Release notes move to `CHANGELOG.md` only.
|
||||
- Delete list from the condensation survey executed, with catalog counts,
|
||||
manifests, and locale mirrors updated in the same PR.
|
||||
- Decide the fate of `continuous-learning` v1 (deprecated since April): remove
|
||||
in [2.3.0] with a migration note, or keep as an archive outside the default
|
||||
install.
|
||||
|
||||
### October
|
||||
|
||||
- `harness-optimizer` and `/harness-audit` produce gate receipts. A skill,
|
||||
hook, or agent change in this repo can cite a receipt in its PR.
|
||||
- Capsule recording behind an opt-in hook flag, journaling tool calls and
|
||||
session boundaries with the default-deny payload allowlist.
|
||||
- First taskset beyond the example: [20 to 60] tasks over one real skill
|
||||
family, with a held-out split and a reward-hack fixture.
|
||||
- Skill catalog review: every skill has a test, a command, an agent, or a
|
||||
README mention, or it is marked for removal in [2.4.0].
|
||||
|
||||
### November
|
||||
|
||||
- 2.3.0: condensation, eval frameworks, and operator skills in one release
|
||||
with the packed-artifact gate.
|
||||
- Retrospective grouping over recorded capsules for one task family, report
|
||||
only, no promotion.
|
||||
- Forced-compaction invariance test in CI for the pinned-state pattern.
|
||||
- AgentShield Pro conversion CTA and hosted scan history behind a flag.
|
||||
|
||||
### Decision points
|
||||
|
||||
- 2026-09-30: is the README under the line target with no test regressions?
|
||||
If not, cut scope on Track A rather than slipping the release.
|
||||
- 2026-10-31: does a real taskset produce a stable verdict across three runs?
|
||||
If variance is high, hold Track B at receipts and do not start retrospective
|
||||
grouping.
|
||||
- 2026-11-30: did any outside user adopt a desk-pattern skill? If none, stop
|
||||
adding operator skills and fold the four into a single guide.
|
||||
|
||||
## Not on this roadmap
|
||||
|
||||
- Online reinforcement learning or weight updates from capsule data.
|
||||
- Production transparency-log witnessing, GPU attestation, or key management
|
||||
inside the ECC package.
|
||||
- Automatic merge or release driven by a gate verdict. The gate stops changes.
|
||||
A person promotes them.
|
||||
- Any desk, payment, provider, or counterparty integration. Those belong to
|
||||
the systems that own them, not to a portable plugin.
|
||||
|
||||
## How to edit this file
|
||||
|
||||
Change the bracketed numbers first. Move items between months freely. When a
|
||||
line ships, delete it here and record it in `CHANGELOG.md`. Keep the file
|
||||
under [200] lines.
|
||||
@@ -703,7 +703,7 @@ Suggested payload:
|
||||
"skippedModules": []
|
||||
},
|
||||
"source": {
|
||||
"repoVersion": "2.2.1",
|
||||
"repoVersion": "2.2.2",
|
||||
"repoCommit": "git-sha",
|
||||
"manifestVersion": 1
|
||||
},
|
||||
|
||||
@@ -1,489 +0,0 @@
|
||||
# ECC Selective Install Design
|
||||
|
||||
## Purpose
|
||||
|
||||
This document defines the user-facing selective-install design for ECC.
|
||||
|
||||
It complements
|
||||
`docs/SELECTIVE-INSTALL-ARCHITECTURE.md`, which focuses on internal runtime
|
||||
architecture and code boundaries.
|
||||
|
||||
This document answers the product and operator questions first:
|
||||
|
||||
- how users choose ECC components
|
||||
- what the CLI should feel like
|
||||
- what config file should exist
|
||||
- how installation should behave across harness targets
|
||||
- how the design maps onto the current ECC codebase without requiring a rewrite
|
||||
|
||||
## Problem
|
||||
|
||||
Today ECC still feels like a large payload installer even though the repo now
|
||||
has first-pass manifest and lifecycle support.
|
||||
|
||||
Users need a simpler mental model:
|
||||
|
||||
- install the baseline
|
||||
- add the language packs they actually use
|
||||
- add the framework configs they actually want
|
||||
- add optional capability packs like security, research, or orchestration
|
||||
|
||||
The selective-install system should make ECC feel composable instead of
|
||||
all-or-nothing.
|
||||
|
||||
In the current substrate, user-facing components are still an alias layer over
|
||||
coarser internal install modules. That means include/exclude is already useful
|
||||
at the module-selection level, but some file-level boundaries remain imperfect
|
||||
until the underlying module graph is split more finely.
|
||||
|
||||
## Goals
|
||||
|
||||
1. Let users install a small default ECC footprint quickly.
|
||||
2. Let users compose installs from reusable component families:
|
||||
- core rules
|
||||
- language packs
|
||||
- framework packs
|
||||
- capability packs
|
||||
- target/platform configs
|
||||
3. Keep one consistent UX across Claude, Cursor, Antigravity, Codex, and
|
||||
OpenCode.
|
||||
4. Keep installs inspectable, repairable, and uninstallable.
|
||||
5. Preserve backward compatibility with the current `ecc-install typescript`
|
||||
style during rollout.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- packaging ECC into multiple npm packages in the first phase
|
||||
- building a remote marketplace
|
||||
- full control-plane UI in the same phase
|
||||
- solving every skill-classification problem before selective install ships
|
||||
|
||||
## User Experience Principles
|
||||
|
||||
### 1. Start Small
|
||||
|
||||
A user should be able to get a useful ECC install with one command:
|
||||
|
||||
```bash
|
||||
ecc install --target claude --profile core
|
||||
```
|
||||
|
||||
The default experience should not assume the user wants every skill family and
|
||||
every framework.
|
||||
|
||||
### 2. Build Up By Intent
|
||||
|
||||
The user should think in terms of:
|
||||
|
||||
- "I want the developer baseline"
|
||||
- "I need TypeScript and Python"
|
||||
- "I want Next.js and Django"
|
||||
- "I want the security pack"
|
||||
|
||||
The user should not have to know raw internal repo paths.
|
||||
|
||||
### 3. Preview Before Mutation
|
||||
|
||||
Every install path should support dry-run planning:
|
||||
|
||||
```bash
|
||||
ecc install --target cursor --profile developer --with lang:typescript --with framework:nextjs --dry-run
|
||||
```
|
||||
|
||||
The plan should clearly show:
|
||||
|
||||
- selected components
|
||||
- skipped components
|
||||
- target root
|
||||
- managed paths
|
||||
- expected install-state location
|
||||
|
||||
### 4. Local Configuration Should Be First-Class
|
||||
|
||||
Teams should be able to commit a project-level install config and use:
|
||||
|
||||
```bash
|
||||
ecc install --config ecc-install.json
|
||||
```
|
||||
|
||||
That allows deterministic installs across contributors and CI.
|
||||
|
||||
## Component Model
|
||||
|
||||
The current manifest already uses install modules and profiles. The user-facing
|
||||
design should keep that internal structure, but present it as four main
|
||||
component families.
|
||||
|
||||
Near-term implementation note: some user-facing component IDs still resolve to
|
||||
shared internal modules, especially in the language/framework layer. The
|
||||
catalog improves UX immediately while preserving a clean path toward finer
|
||||
module granularity in later phases.
|
||||
|
||||
### 1. Baseline
|
||||
|
||||
These are the default ECC building blocks:
|
||||
|
||||
- core rules
|
||||
- baseline agents
|
||||
- core commands
|
||||
- runtime hooks
|
||||
- platform configs
|
||||
- workflow quality primitives
|
||||
|
||||
Examples of current internal modules:
|
||||
|
||||
- `rules-core`
|
||||
- `agents-core`
|
||||
- `commands-core`
|
||||
- `hooks-runtime`
|
||||
- `platform-configs`
|
||||
- `workflow-quality`
|
||||
|
||||
### 2. Language Packs
|
||||
|
||||
Language packs group rules, guidance, and workflows for a language ecosystem.
|
||||
|
||||
Examples:
|
||||
|
||||
- `lang:typescript`
|
||||
- `lang:python`
|
||||
- `lang:go`
|
||||
- `lang:java`
|
||||
- `lang:rust`
|
||||
|
||||
Each language pack should resolve to one or more internal modules plus
|
||||
target-specific assets.
|
||||
|
||||
### 3. Framework Packs
|
||||
|
||||
Framework packs sit above language packs and pull in framework-specific rules,
|
||||
skills, and optional setup.
|
||||
|
||||
Examples:
|
||||
|
||||
- `framework:react`
|
||||
- `framework:nextjs`
|
||||
- `framework:django`
|
||||
- `framework:springboot`
|
||||
- `framework:laravel`
|
||||
|
||||
Framework packs should depend on the correct language pack or baseline
|
||||
primitives where appropriate.
|
||||
|
||||
### 4. Capability Packs
|
||||
|
||||
Capability packs are cross-cutting ECC feature bundles.
|
||||
|
||||
Examples:
|
||||
|
||||
- `capability:security`
|
||||
- `capability:research`
|
||||
- `capability:orchestration`
|
||||
- `capability:media`
|
||||
- `capability:content`
|
||||
|
||||
These should map onto the current module families already being introduced in
|
||||
the manifests.
|
||||
|
||||
## Profiles
|
||||
|
||||
Profiles remain the fastest on-ramp.
|
||||
|
||||
Recommended user-facing profiles:
|
||||
|
||||
- `core`
|
||||
minimal baseline, safe default for most users trying ECC
|
||||
- `developer`
|
||||
best default for active software engineering work
|
||||
- `security`
|
||||
baseline plus security-heavy guidance
|
||||
- `research`
|
||||
baseline plus research/content/investigation tools
|
||||
- `full`
|
||||
everything classified and currently supported
|
||||
|
||||
Profiles should be composable with additional `--with` and `--without` flags.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
ecc install --target claude --profile developer --with lang:typescript --with framework:nextjs --without capability:orchestration
|
||||
```
|
||||
|
||||
## Proposed CLI Design
|
||||
|
||||
### Primary Commands
|
||||
|
||||
```bash
|
||||
ecc install
|
||||
ecc plan
|
||||
ecc list-installed
|
||||
ecc doctor
|
||||
ecc repair
|
||||
ecc uninstall
|
||||
ecc catalog
|
||||
```
|
||||
|
||||
### Install CLI
|
||||
|
||||
Recommended shape:
|
||||
|
||||
```bash
|
||||
ecc install [--target <target>] [--profile <name>] [--with <component>]... [--without <component>]... [--config <path>] [--dry-run] [--json]
|
||||
```
|
||||
|
||||
Examples:
|
||||
|
||||
```bash
|
||||
ecc install --target claude --profile core
|
||||
ecc install --target cursor --profile developer --with lang:typescript --with framework:nextjs
|
||||
ecc install --target antigravity --with capability:security --with lang:python
|
||||
ecc install --config ecc-install.json
|
||||
```
|
||||
|
||||
### Plan CLI
|
||||
|
||||
Recommended shape:
|
||||
|
||||
```bash
|
||||
ecc plan [same selection flags as install]
|
||||
```
|
||||
|
||||
Purpose:
|
||||
|
||||
- produce a preview without mutation
|
||||
- act as the canonical debugging surface for selective install
|
||||
|
||||
### Catalog CLI
|
||||
|
||||
Recommended shape:
|
||||
|
||||
```bash
|
||||
ecc catalog profiles
|
||||
ecc catalog components
|
||||
ecc catalog components --family language
|
||||
ecc catalog show framework:nextjs
|
||||
```
|
||||
|
||||
Purpose:
|
||||
|
||||
- let users discover valid component names without reading docs
|
||||
- keep config authoring approachable
|
||||
|
||||
### Compatibility CLI
|
||||
|
||||
These legacy flows should still work during migration:
|
||||
|
||||
```bash
|
||||
ecc-install typescript
|
||||
ecc-install --target cursor typescript
|
||||
ecc typescript
|
||||
```
|
||||
|
||||
Internally these should normalize into the new request model and write
|
||||
install-state the same way as modern installs.
|
||||
|
||||
## Proposed Config File
|
||||
|
||||
### Filename
|
||||
|
||||
Recommended default:
|
||||
|
||||
- `ecc-install.json`
|
||||
|
||||
Optional future support:
|
||||
|
||||
- `.ecc/install.json`
|
||||
|
||||
### Config Shape
|
||||
|
||||
```json
|
||||
{
|
||||
"$schema": "./schemas/ecc-install-config.schema.json",
|
||||
"version": 1,
|
||||
"target": "cursor",
|
||||
"profile": "developer",
|
||||
"include": [
|
||||
"lang:typescript",
|
||||
"lang:python",
|
||||
"framework:nextjs",
|
||||
"capability:security"
|
||||
],
|
||||
"exclude": [
|
||||
"capability:media"
|
||||
],
|
||||
"options": {
|
||||
"hooksProfile": "standard",
|
||||
"mcpCatalog": "baseline",
|
||||
"includeExamples": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Field Semantics
|
||||
|
||||
- `target`
|
||||
selected harness target such as `claude`, `cursor`, or `antigravity`
|
||||
- `profile`
|
||||
baseline profile to start from
|
||||
- `include`
|
||||
additional components to add
|
||||
- `exclude`
|
||||
components to subtract from the profile result
|
||||
- `options`
|
||||
target/runtime tuning flags that do not change component identity
|
||||
|
||||
### Precedence Rules
|
||||
|
||||
1. CLI arguments override config file values.
|
||||
2. config file overrides profile defaults.
|
||||
3. profile defaults override internal module defaults.
|
||||
|
||||
This keeps the behavior predictable and easy to explain.
|
||||
|
||||
## Modular Installation Flow
|
||||
|
||||
The user-facing flow should be:
|
||||
|
||||
1. load config file if provided or auto-detected
|
||||
2. merge CLI intent on top of config intent
|
||||
3. normalize the request into a canonical selection
|
||||
4. expand profile into baseline components
|
||||
5. add `include` components
|
||||
6. subtract `exclude` components
|
||||
7. resolve dependencies and target compatibility
|
||||
8. render a plan
|
||||
9. apply operations if not in dry-run mode
|
||||
10. write install-state
|
||||
|
||||
The important UX property is that the exact same flow powers:
|
||||
|
||||
- `install`
|
||||
- `plan`
|
||||
- `repair`
|
||||
- `uninstall`
|
||||
|
||||
The commands differ in action, not in how ECC understands the selected install.
|
||||
|
||||
## Target Behavior
|
||||
|
||||
Selective install should preserve the same conceptual component graph across all
|
||||
targets, while letting target adapters decide how content lands.
|
||||
|
||||
### Claude
|
||||
|
||||
Best fit for:
|
||||
|
||||
- home-scoped ECC baseline
|
||||
- commands, agents, rules, hooks, platform config, orchestration
|
||||
|
||||
### Cursor
|
||||
|
||||
Best fit for:
|
||||
|
||||
- project-scoped installs
|
||||
- rules plus project-local automation and config
|
||||
|
||||
### Antigravity
|
||||
|
||||
Best fit for:
|
||||
|
||||
- project-scoped agent/rule/workflow installs
|
||||
|
||||
### Codex / OpenCode
|
||||
|
||||
Should remain additive targets rather than special forks of the installer.
|
||||
|
||||
The selective-install design should make these just new adapters plus new
|
||||
target-specific mapping rules, not new installer architectures.
|
||||
|
||||
## Technical Feasibility
|
||||
|
||||
This design is feasible because the repo already has:
|
||||
|
||||
- install module and profile manifests
|
||||
- target adapters with install-state paths
|
||||
- plan inspection
|
||||
- install-state recording
|
||||
- lifecycle commands
|
||||
- a unified `ecc` CLI surface
|
||||
|
||||
The missing work is not conceptual invention. The missing work is productizing
|
||||
the current substrate into a cleaner user-facing component model.
|
||||
|
||||
### Feasible In Phase 1
|
||||
|
||||
- profile + include/exclude selection
|
||||
- `ecc-install.json` config file parsing
|
||||
- catalog/discovery command
|
||||
- alias mapping from user-facing component IDs to internal module sets
|
||||
- dry-run and JSON planning
|
||||
|
||||
### Feasible In Phase 2
|
||||
|
||||
- richer target adapter semantics
|
||||
- merge-aware operations for config-like assets
|
||||
- stronger repair/uninstall behavior for non-copy operations
|
||||
|
||||
### Later
|
||||
|
||||
- reduced publish surface
|
||||
- generated slim bundles
|
||||
- remote component fetch
|
||||
|
||||
## Mapping To Current ECC Manifests
|
||||
|
||||
The current manifests do not yet expose a true user-facing `lang:*` /
|
||||
`framework:*` / `capability:*` taxonomy. That should be introduced as a
|
||||
presentation layer on top of the existing modules, not as a second installer
|
||||
engine.
|
||||
|
||||
Recommended approach:
|
||||
|
||||
- keep `install-modules.json` as the internal resolution catalog
|
||||
- add a user-facing component catalog that maps friendly component IDs to one or
|
||||
more internal modules
|
||||
- let profiles reference either internal modules or user-facing component IDs
|
||||
during the migration window
|
||||
|
||||
That avoids breaking the current selective-install substrate while improving UX.
|
||||
|
||||
## Suggested Rollout
|
||||
|
||||
### Phase 1: Design And Discovery
|
||||
|
||||
- finalize the user-facing component taxonomy
|
||||
- add the config schema
|
||||
- add CLI design and precedence rules
|
||||
|
||||
### Phase 2: User-Facing Resolution Layer
|
||||
|
||||
- implement component aliases
|
||||
- implement config-file parsing
|
||||
- implement `include` / `exclude`
|
||||
- implement `catalog`
|
||||
|
||||
### Phase 3: Stronger Target Semantics
|
||||
|
||||
- move more logic into target-owned planning
|
||||
- support merge/generate operations cleanly
|
||||
- improve repair/uninstall fidelity
|
||||
|
||||
### Phase 4: Packaging Optimization
|
||||
|
||||
- narrow published surface
|
||||
- evaluate generated bundles
|
||||
|
||||
## Recommendation
|
||||
|
||||
The next implementation move should not be "rewrite the installer."
|
||||
|
||||
It should be:
|
||||
|
||||
1. keep the current manifest/runtime substrate
|
||||
2. add a user-facing component catalog and config file
|
||||
3. add `include` / `exclude` selection and catalog discovery
|
||||
4. let the existing planner and lifecycle stack consume that model
|
||||
|
||||
That is the shortest path from the current ECC codebase to a real selective
|
||||
install experience that feels like ECC 2.0 instead of a large legacy installer.
|
||||
@@ -59,6 +59,9 @@ Adapters should stay thin. The shared behavior belongs in `skills/`, `rules/`, `
|
||||
|
||||
## Shared Memory Contract
|
||||
|
||||
The session snapshot side of this contract (`ecc.session.v1`) is specified in
|
||||
[session-adapter-contract.md](session-adapter-contract.md).
|
||||
|
||||
ECC Memory Vault is the common knowledge-transfer surface for Claude, Codex,
|
||||
Hermes, Cursor, OpenCode, and other agents. It stores portable
|
||||
`ecc.memory.v1` Markdown documents in three scopes:
|
||||
|
||||
@@ -0,0 +1,391 @@
|
||||
# Eval Harness Frameworks
|
||||
|
||||
Local capsule, inspection, fixture replay, and receipt building blocks.
|
||||
Candidate execution and promotion are unavailable.
|
||||
They live in `scripts/lib/eval-harness/`, ship with a CLI at
|
||||
`scripts/eval-harness.js`, and have an end-to-end example under
|
||||
`examples/eval-harness/`. The example runs locally, offline, and inside temporary
|
||||
directories. It does not merge, deploy, publish, or spend.
|
||||
|
||||
```sh
|
||||
node scripts/eval-harness.js example
|
||||
```
|
||||
|
||||
## Why these five
|
||||
|
||||
The harness engineering plan v2 (August 2026) describes a twelve-layer stack.
|
||||
The part that belongs in the portable ECC package is the contract surface any
|
||||
harness can install and exercise: record what happened, prove it was not
|
||||
altered, gate a proposed change behind an external checker, replay tool calls
|
||||
without re-firing effects, and hand a verifier something it can check without
|
||||
trusting the producer. The execution gate remains disabled pending a verified OS containment backend.
|
||||
The other modules expose local utilities, not a trust decision about code.
|
||||
|
||||
| Framework | Module | Plan epic | What it gives you today |
|
||||
| --- | --- | --- | --- |
|
||||
| Envelope | `envelope.js`, `schemas/capsule-envelope.schema.json` | 01 telemetry and capsule contract | `capsule-envelope/v1`, stable identifiers, effect classes SE0 to SE4, default-deny payload allowlist, secret canaries |
|
||||
| Capsule | `capsule.js` | 02 local execution capsule | Append-only NDJSON journal, five lineages, sha256 predecessor links, `verify` that fails at the exact entry, byte-stable projection, minimal export bundle |
|
||||
| Gate | `gate.js`, `gate-child.js` | 03 verification gate | Static source digests and syntactic warnings; all execution entrypoints refuse |
|
||||
| Replay | `replay.js`, `effect-fence.js` | 04 replay-safe branching | Declared determinism and effect class per tool, content-addressed fixtures, `tool.fixture_missing` fail-closed replay, retired child preload refuses execution |
|
||||
| Receipt | `receipt.js` | 07 verifiable receipts | Offline receipt over capsule root, entry count, artifact digest, and gate receipt; detached signature interface; verification names the failing check |
|
||||
|
||||
Epic 05 has an offline, report-only capsule grouping utility described below.
|
||||
Self-improvement, operational retrospective validation and epic 06 (causal
|
||||
triage and compaction invariance) remain unimplemented. They consume the
|
||||
records these five frameworks produce.
|
||||
|
||||
## Effect classes
|
||||
|
||||
Every journal entry, tool declaration, and variant manifest carries one class.
|
||||
|
||||
| Class | Meaning | Where it is allowed |
|
||||
| --- | --- | --- |
|
||||
| SE0 | Read-only evaluation or schema validation | Everywhere |
|
||||
| SE1 | Reversible local writes inside the capsule or work root | Journal, gate metadata |
|
||||
| SE2 | Process or filesystem mutation, no live network writes | Candidate execution unavailable |
|
||||
| SE3 | Append-only remote evidence publication | Never in replay; trusted record-mode caller controls authorization; refused in replay |
|
||||
| SE4 | Economic, counterparty, payment, provider, or secret-handling effects | Never in replay; record mode requires the trusted caller to forbid it |
|
||||
|
||||
Effect classes are declarations, not OS permissions. Static inspection reports
|
||||
effect-class expansion but cannot enforce a declaration. The replayer refuses
|
||||
SE3 and above in replay mode regardless of fixtures; record mode invokes the
|
||||
caller-supplied implementation up to its configured maximum. Only register
|
||||
trusted implementations. No JavaScript tool wrapper isolates arbitrary code.
|
||||
|
||||
## Capsule journal
|
||||
|
||||
A capsule is a directory with `capsule.json`, `journal.ndjson`, and an optional
|
||||
`projection.json`. Each line of the journal is one canonical-JSON envelope. The
|
||||
first entry links to sixty-four zeros; every later entry links to the previous
|
||||
`entry_hash`.
|
||||
|
||||
```js
|
||||
const { capsule } = require('./scripts/lib/eval-harness');
|
||||
const c = capsule.Capsule.create('.ecc/capsules/run-42', { task_family: 'slugify' });
|
||||
c.append('plan', 'inspection.start', { task_id: 't01' });
|
||||
c.append('attempt', 'gate.unavailable', { status: 'blocked', reason: 'gate.isolation_required' });
|
||||
capsule.verify('.ecc/capsules/run-42'); // { ok, code, failed_at, root_hash }
|
||||
```
|
||||
|
||||
`verify` returns `ok: false` with a stable code and the exact failing index for
|
||||
a changed byte (`capsule.invalid_entry`), a dropped or swapped entry
|
||||
(`capsule.reordered` or `capsule.broken_link`), and a partial trailing write
|
||||
(`capsule.truncated_tail`). The journal digest covers the original bytes;
|
||||
invalid UTF-8 is rejected as `capsule.non_canonical`. `project` derives stable
|
||||
content from the verified journal snapshot and validated metadata. `exportBundle`
|
||||
copies the three capsule files and nothing from the workspace.
|
||||
|
||||
Metadata is validated before creation writes and when opening, verifying or
|
||||
projecting a capsule. IDs use the envelope ID pattern; harness/task family must
|
||||
be nonempty, and created_at must use the canonical ISO timestamp produced by
|
||||
Date.toISOString(). Missing, unreadable or malformed metadata returns
|
||||
`capsule.metadata_invalid`; invalid UTF-8 is also rejected. Every journal entry must match metadata schema,
|
||||
run_id, capsule_id, harness_version and task_family, or verification returns
|
||||
`capsule.metadata_mismatch` at that entry. Empty journals have no historical
|
||||
identity binding; their projection and receipt bind the metadata values.
|
||||
created_at is shape-checked but is not authenticated by journal entries.
|
||||
|
||||
Envelope v1 enforces the scalar payload types declared in
|
||||
`schemas/capsule-envelope.schema.json`. String fields require strings; number
|
||||
fields require finite numbers, and integer fields require integers. Only
|
||||
`exit_code` accepts null. No extra nonnegative restrictions are imposed on these
|
||||
payload numbers. Omitted append payloads still default to an empty object.
|
||||
Explicit null, arrays, primitives, exotic objects, accessors, symbol keys and
|
||||
non-enumerable properties are rejected. Plain data objects with either the normal
|
||||
or null prototype are accepted. Validation inspects descriptors before reading
|
||||
values; it does not isolate proxies or arbitrary caller JavaScript.
|
||||
|
||||
Retained fields are validated before canary scanning or hashing. Undefined,
|
||||
non-finite numbers, functions, symbols, BigInt and nested/cyclic objects are
|
||||
refused instead of coerced, dropped from serialized bytes or recursively scanned.
|
||||
`redactPayload` adds an `errors` array to its existing result; callers must check
|
||||
it alongside `dropped` and `findings`. Append reports `capsule.payload_invalid`
|
||||
without writing a journal entry; the existing finally path releases its owned
|
||||
lock. Strict unknown payload keys still report `capsule.payload_denied`.
|
||||
`strict: false` permits dropping unknown keys, but never invalid retained values.
|
||||
Custom allowlists can narrow v1 fields only, and cannot widen the persisted schema.
|
||||
|
||||
Envelope validation also requires its own schema-defined fields and rejects
|
||||
unknown top-level fields even when the supplied hash has been recomputed. Invalid
|
||||
stored records return `capsule.invalid_entry` at their journal index. This tightens
|
||||
acceptance of malformed v1 data: existing nonconforming callers/journals need
|
||||
explicit correction; no automatic migration or healing is performed. Valid v1
|
||||
bytes and hashes remain unchanged. Generic key preservation and remaining
|
||||
non-JSON limitations are described below; neither supplies OS containment.
|
||||
|
||||
The generic canonicalizer preserves every selected own enumerable JSON key as an
|
||||
own data property, including `__proto__`, `constructor` and `prototype`. It does
|
||||
not invoke an inherited setter while constructing the canonical object. Results
|
||||
retain their ordinary object prototype. Envelope schema rejection is separate:
|
||||
an own `__proto__` key is valid generic JSON data but remains an unknown envelope
|
||||
field. Receipt schema acceptance is unchanged; hashing a field is not permission
|
||||
from a higher-level schema.
|
||||
|
||||
Traversal, key sorting, array handling, undefined omission, JSON.stringify and
|
||||
UTF-8 hashing retain their prior policy, including JavaScript's ordering of
|
||||
numeric-looking keys. Schema-valid v1 journal/projection bytes and unaffected
|
||||
receipt/fixture bytes stay identical. Regression vectors were captured from the
|
||||
pre-fix implementation, including unsigned and synthetic string-signed receipts.
|
||||
Verification does not rewrite those stored artifacts.
|
||||
|
||||
The earlier canonicalizer omitted own `__proto__` keys, creating hash aliases.
|
||||
Corrected inputs retaining that key intentionally produce different hashes. An
|
||||
artifact retaining it with a legacy digest fails existing hash checks; a fixture
|
||||
lookup does not fall back to the old aliased key. Existing key-free stored bytes
|
||||
remain readable as those bytes, but cannot authenticate richer original inputs
|
||||
whose keys were lost. Recovery requires explicit re-recording from a trusted
|
||||
source or receipt rebuilding/re-signing; there is no automatic rekey, migration,
|
||||
rewrite, dual-hash acceptance or recovery of already discarded information.
|
||||
|
||||
This correction does not define a stricter generic policy for undefined,
|
||||
functions/symbols, non-finite numbers, sparse arrays, class/toJSON/getter behavior,
|
||||
cycles, resource limits or hostile proxies. Their prior behavior remains; no
|
||||
claim of unambiguous hashing for every JavaScript value is made. The envelope's
|
||||
stricter scalar validation remains a separate layer.
|
||||
|
||||
Append operations serialize cooperating writers using an exclusive local
|
||||
`.append.lock` file. Acquisition uses `wx` and fails immediately with
|
||||
`capsule.busy` when the path exists, regardless of age or contents. There is no
|
||||
waiting, retry, PID/age heuristic, or automatic stale unlocking. Under ownership,
|
||||
each append reloads and verifies the complete journal and metadata, then derives
|
||||
its sequence and predecessor hash from that snapshot. Preopened handles never
|
||||
use cached sequence/hash values as authoritative state. Full validation costs
|
||||
O(journal size) per append; this implementation is intended for small local
|
||||
journals.
|
||||
|
||||
The writer handles short writes until the complete UTF-8 entry has been written,
|
||||
then fsyncs the journal. The append lock is released in finally on success,
|
||||
validation refusal, or ordinary I/O exceptions. A zero-progress write returns
|
||||
`capsule.write_failed`. Release checks the open lock descriptor's device/inode
|
||||
against the path before unlinking; a detected missing/replaced lock returns
|
||||
`capsule.lock_lost` and a replacement is preserved. This is cooperative ownership
|
||||
checking, not atomic protection against an actor replacing paths between syscalls.
|
||||
The local filesystem must support exclusive file creation and stable identities.
|
||||
|
||||
A process crash can leave `.append.lock` behind. Acquisition/cleanup I/O failures
|
||||
can also leave a lock that was not safely released. Further appends stay busy;
|
||||
only an operator who has stopped all writers and inspected the capsule should
|
||||
perform recovery. The library never guesses ownership, removes an old lock,
|
||||
truncates a tail, or repairs journal bytes automatically.
|
||||
|
||||
A write failure may leave a partial entry; later appends verify the journal and
|
||||
refuse the invalid tail, preserving evidence. A full entry may already exist when
|
||||
fsync, close or lock release throws. Such a failure is an ambiguous acknowledgement,
|
||||
not proof of rollback: inspect disk before retrying, or a logical event could be
|
||||
recorded twice. No transaction, exactly-once retry, parent-directory fsync, or
|
||||
power-loss durability guarantee is added here.
|
||||
|
||||
Create, read/verify, projection, receipt production and export are not serialized
|
||||
by the append lock. Use quiescent capsules for consistent receipts/exports; there
|
||||
is no concurrent export guarantee or hostile-filesystem containment. The append
|
||||
repair does not change the disabled candidate execution boundary.
|
||||
|
||||
What the chain does not claim: it does not stop an operator from replacing the
|
||||
whole log. That is the job of a witnessed transparency log, which is a later,
|
||||
opt-in layer outside this package.
|
||||
|
||||
## Offline retrospective preparation
|
||||
|
||||
Select 1 to 100 existing capsule directories from one task family:
|
||||
|
||||
```sh
|
||||
node scripts/eval-harness.js capsule group .ecc/capsules/run-41 .ecc/capsules/run-42
|
||||
```
|
||||
|
||||
```js
|
||||
const { retrospective } = require('./scripts/lib/eval-harness');
|
||||
const report = retrospective.groupCapsules(['.ecc/capsules/run-41', '.ecc/capsules/run-42']);
|
||||
```
|
||||
|
||||
This read-only utility recomputes each projection from the verified metadata and
|
||||
journal snapshot using `capsule.project`. It never uses or repairs a saved
|
||||
`projection.json`. Inputs must be small, quiescent local capsules from the same
|
||||
task family; a mismatch rejects the entire report. There is no directory
|
||||
discovery, hook activation, new rollout, fixture replay or candidate execution.
|
||||
|
||||
`capsule-retrospective/v1` reports the task family, input count, unique capsule
|
||||
count, duplicate count, and groups sorted by declared harness version. Each
|
||||
group contains capsule/entry counts, all five lineage counts, all five declared
|
||||
effect-class counts, and source digest references. Counts describe recorded
|
||||
entries, not unique tasks, attempts, successful effects or independently
|
||||
verified outcomes. Empty journals contribute one capsule and zero entries.
|
||||
Payload scores, verdicts, costs, durations and pass/fail totals are not used.
|
||||
|
||||
The pair `(run_id, capsule_id)` identifies a capsule for deduplication. Repeated
|
||||
paths or copied snapshots count once when their verified projection hashes
|
||||
match. Conflicting snapshots of that identity, including different checkpoints,
|
||||
fail with `retrospective.conflicting_identity`; the utility never picks a winner.
|
||||
Distinct capsule identities remain distinct even if their event shapes match.
|
||||
Source references contain the canonical hash of the identity pair, entry count,
|
||||
root hash, journal digest and projection hash. `report_hash` covers every other
|
||||
report field; input ordering does not change the result. Repeating an input
|
||||
changes input/duplicate counts and the report hash, but not the grouped counts.
|
||||
|
||||
Reports omit directory arguments, raw run/capsule IDs, journal payloads and
|
||||
timestamps. **Task-family and harness-version labels are returned verbatim**
|
||||
and may themselves contain private text or paths. Digest references are not
|
||||
anonymization: they remain linkable and low-entropy IDs can be guessed. Review
|
||||
labels and report content before sharing. Neither hashes nor declared labels
|
||||
authenticate a producer or prove an improvement; `report_only` is always true.
|
||||
|
||||
Any invalid, unreadable or mismatched capsule rejects the whole report with
|
||||
`retrospective.invalid_capsule` and a zero-based input index. Diagnostics omit
|
||||
underlying reader messages and source paths. Mixed families and invalid input
|
||||
lists have separate stable codes. CLI success emits JSON to stdout and exits 0;
|
||||
bad usage exits 2, while verification/refusal exits 1 without partial JSON.
|
||||
The command accepts no flags and does not write a report file. For a directory
|
||||
name beginning with `--`, use a relative `./` prefix or an absolute path.
|
||||
|
||||
This inherits the existing capsule reader's filesystem and memory limits. The
|
||||
100-input cap does not bound journal bytes. It does not isolate hostile files,
|
||||
serialize concurrent writers, validate a signature or establish live provenance.
|
||||
Executor containment, opt-in hook recording, stable-taskset validation and the
|
||||
roadmap's operational retrospective milestone remain separate prerequisites.
|
||||
|
||||
## Verification gate: unavailable
|
||||
|
||||
**Supported candidate execution backends: none, on any OS.** `runGate` and
|
||||
`runVariant` throw `gate.isolation_required` unconditionally, before reading
|
||||
configuration, copying files, loading candidate modules, or creating receipts.
|
||||
`gate run` exits 1 before reading its config or creating a capsule. Direct
|
||||
`gate-child.js` invocation and the retired `effect-fence.js` preload also refuse
|
||||
before loading requests or candidate code. Trust flags and caller-supplied
|
||||
executor objects cannot enable execution. There is no promotion path.
|
||||
|
||||
The former directory copy and JavaScript interception did not isolate host
|
||||
reads, alternate builtin loaders, or filesystem descriptors and promises.
|
||||
Keeping answers in a parent process did not hide the taskset on disk. The
|
||||
interception code and staged execution implementation have been removed.
|
||||
Node's [permission model](https://nodejs.org/api/permissions.html) and
|
||||
[`vm` module](https://nodejs.org/api/vm.html) are not substitutes for isolation
|
||||
of malicious code.
|
||||
|
||||
A future executor must have a separately reviewed OS containment implementation
|
||||
and adversarial evidence on each supported OS. At minimum it must:
|
||||
|
||||
- Expose only immutable, digested variant files and task inputs in an ephemeral
|
||||
filesystem. Host tasksets, answers, credentials, configuration, sockets, and
|
||||
other workspaces must be inaccessible, including via links and inherited FDs.
|
||||
- Enforce network, process, filesystem, and resource restrictions outside the
|
||||
candidate runtime, with an unprivileged identity and a bounded lifetime.
|
||||
- Keep the checker, output/protocol validation, audit channel, and receipt
|
||||
creation outside candidate control. Verify the actual runtime policy using
|
||||
independent canaries before any candidate starts; refuse unavailable backends.
|
||||
- Reject failed, timed-out, signalled, incomplete, or malformed baseline runs
|
||||
before evaluating candidate improvements. Require a complete unique result
|
||||
for each task. Container availability or a caller's `verified: true` assertion
|
||||
alone is not policy verification.
|
||||
|
||||
Static APIs remain available for trusted, quiescent local source trees:
|
||||
`loadTaskset`, `loadVariant`, `digestDir`, and `scanTripwires`. Variant names are
|
||||
single components of 1–64 ASCII letters, digits, underscores or hyphens, starting
|
||||
with a letter or digit. Entries must be relative regular files included in the
|
||||
digest; absolute, parent-traversing, symlinked, and excluded entries are rejected.
|
||||
`.git` and `node_modules` remain excluded. Inspection does not resist concurrent
|
||||
host filesystem mutation and is not a sandbox or an execution attestation.
|
||||
Task IDs must be unique. Syntactic warnings are incomplete by design: zero hits
|
||||
prove neither safety nor correctness.
|
||||
|
||||
`parseChildResult` and `baselineFailure(run, tasks)` are pure validation helpers
|
||||
for bounded protocol and baseline integrity regression checks. No executor calls
|
||||
them in this release. Their tests are not evidence of an operational gate or a
|
||||
verified OS backend. Existing manifest/config fixtures are preserved as data.
|
||||
|
||||
## Replay-safe tool calls
|
||||
|
||||
```js
|
||||
const { replay } = require('./scripts/lib/eval-harness');
|
||||
const store = new replay.FixtureStore('.ecc/fixtures');
|
||||
const tools = {
|
||||
read_inventory: { effect_class: 'SE0', determinism: 'deterministic', impl: liveRead },
|
||||
place_order: { effect_class: 'SE4', determinism: 'nondeterministic', impl: livePlace },
|
||||
};
|
||||
const r = replay.createReplayer(tools, { mode: 'replay', store, maxEffectClass: 'SE2' });
|
||||
r.call('read_inventory', { sku: 'gpu-8x' }); // served from fixture or tool.fixture_missing
|
||||
r.call('place_order', { sku: 'gpu-8x' }); // tool.effect_forbidden, always
|
||||
```
|
||||
|
||||
Fixtures are keyed by the canonical hash of `(tool, args)` and store both an
|
||||
argument hash and a response hash, so a stale or edited fixture fails with
|
||||
`tool.fixture_mismatch`. Record mode executes caller-supplied trusted functions;
|
||||
replay uses fixtures. These wrappers do not constrain arbitrary effects inside
|
||||
an implementation. The legacy `EFFECT_FENCE_PRELOAD` export remains for import
|
||||
compatibility, but loading that file always throws `gate.isolation_required`.
|
||||
It no longer attempts JavaScript interception.
|
||||
|
||||
## Offline receipts
|
||||
|
||||
```sh
|
||||
node scripts/eval-harness.js receipt build .ecc/capsules/run-42 \
|
||||
--artifact skills/my-skill/SKILL.md --out run-42.receipt.json
|
||||
node scripts/eval-harness.js receipt verify run-42.receipt.json exported-bundle/ \
|
||||
--artifact skills/my-skill/SKILL.md
|
||||
```
|
||||
|
||||
A receipt names the capsule root, entry count, journal digest, projection
|
||||
hash, artifact digest, and optional gate receipt digest, plus its own hash.
|
||||
`buildReceipt` now persists `projection.json` using the verified journal snapshot
|
||||
before returning the receipt. This is a producer write and can fail on a read-only
|
||||
capsule; copy a read-only source to a writable local directory before building.
|
||||
An explicit invalid artifact_digest throws `receipt.schema_invalid` before the
|
||||
projection write. Other construction failures continue to throw.
|
||||
|
||||
`verifyReceipt` is read-only. It never regenerates or heals a missing projection.
|
||||
The supplied projection must parse and match the complete deterministic projection
|
||||
from the validated metadata/journal snapshot; its computed hash must match both
|
||||
its stored projection_hash and the receipt. Missing, unreadable, corrupt or
|
||||
substituted projections return `check: 'projection'`; invalid UTF-8 is rejected. Receipt identity mismatches
|
||||
and invalid capsule metadata return `check: 'metadata'`.
|
||||
|
||||
Schema validation rejects negative, fractional, string or unsafe entry counts,
|
||||
invalid identity/schema values and malformed required digests before journal
|
||||
indexing. Optional artifact/gate digest fields must be SHA-256 values or null.
|
||||
Otherwise valid receipts retain signature, journal integrity, truncation,
|
||||
capsule-root and stale-checkpoint checks before projection/artifact comparisons.
|
||||
Missing or unreadable artifact files return `check: 'artifact'` rather than
|
||||
throwing. Every verification failure has `{ok: false, check, reason}` for these
|
||||
validated file/content cases.
|
||||
|
||||
Existing v1 exported bundles retain their format. Older source directories whose
|
||||
receipts were built without a saved projection must explicitly run `capsule
|
||||
project` or rebuild the receipt before verification; verification itself never
|
||||
writes a replacement. The CLI validates --artifact, --gate and --out before file
|
||||
reads or producer writes: missing values, values that are another flag, and
|
||||
repeated flags exit with usage code 2. Disabled gate commands still refuse before
|
||||
configuration/capsule I/O.
|
||||
|
||||
Signing remains a detached interface: pass a signer when building and a verifier
|
||||
when verifying. No key generation, transport or rotation happens in this package.
|
||||
A signature proves who vouched for the bytes, not that the run was correct.
|
||||
Optional gate-receipt hashing remains for compatibility with existing artifacts;
|
||||
accepting externally supplied bytes proves neither containment nor promotion.
|
||||
|
||||
This slice addresses receipt/projection validation and metadata identity binding.
|
||||
The OS executor is still unavailable. Cooperative append serialization is
|
||||
described above; concurrent export/create and broader envelope/review findings
|
||||
remain separate. Package/count evidence is a separate ignore-scripts test scope
|
||||
and does not validate normal prepack or clear a release.
|
||||
|
||||
## Where it plugs in
|
||||
|
||||
- `skills/eval-harness/SKILL.md` describes eval-driven development. These
|
||||
frameworks are the mechanical layer under its report format.
|
||||
- The `harness-optimizer` agent and `/harness-audit` command must report the gate
|
||||
unavailable until a reviewed OS backend exists. They cannot emit new gate
|
||||
receipts using this implementation.
|
||||
- The Rust `ecc2/src/harness_eval.rs` bounded evaluation loop is a separate,
|
||||
earlier experiment. The Node frameworks are the portable surface.
|
||||
|
||||
## Tests
|
||||
|
||||
```sh
|
||||
node tests/lib/eval-harness/envelope.test.js
|
||||
node tests/lib/eval-harness/capsule.test.js
|
||||
node tests/lib/eval-harness/retrospective.test.js
|
||||
node tests/lib/eval-harness/gate.test.js
|
||||
node tests/lib/eval-harness/security.test.js
|
||||
node tests/lib/eval-harness/replay.test.js
|
||||
node tests/lib/eval-harness/receipt.test.js
|
||||
node tests/lib/eval-harness/cli.test.js
|
||||
node examples/eval-harness/run-example.js
|
||||
```
|
||||
@@ -0,0 +1,81 @@
|
||||
# TCAS hook: pre-merge deconfliction (slice b, design)
|
||||
|
||||
Status: design only. Nothing in this document is implemented. Slice (a), the live view and the advisory feed it reads, shipped in `VIEW-CONTRACT.md`.
|
||||
|
||||
## Goal
|
||||
|
||||
Stop two agents from finishing overlapping edits and meeting at the merge. The scan already knows when two working sets converge; the hook is what turns that knowledge into a maneuver inside the harness, before either agent commits.
|
||||
|
||||
Push plan wording: "a PreToolUse/Edit hook that reads the advisory feed and returns steer, pause or wait for the lower-priority agent, logged to the capsule."
|
||||
|
||||
## Inputs
|
||||
|
||||
1. The event feed: `GET /api/control-plane/events` on the local control pane, or the same document written to a file by `scripts/proximity-tick.js --json` for sessions without a pane. Events of kind `proximity.advisory` with `action.type` `transmit` or `steer` and a deterministic `id`.
|
||||
2. The hook's own session id. Claude Code passes `session_id` on stdin; the ECC session adapter maps it to the ECC2 `sessions.id` the scan uses. Codex and Hermes use the instruction-backed equivalent (see below).
|
||||
3. The tool call: `tool_name` and `tool_input.file_path` for Edit, Write and MultiEdit. Bash is out of scope for v1.
|
||||
|
||||
## Decision
|
||||
|
||||
For each advisory event whose `subject` includes this session:
|
||||
|
||||
| Event | This session is | Maneuver | Hook result |
|
||||
|---|---|---|---|
|
||||
| `traffic`, action `transmit` | either side | **transmit**: inject the other agent's working set as a system message | exit 0, message on stderr (warn, never block) |
|
||||
| `resolution`, action `steer` | `hold` | **hold**: continue | exit 0, short note |
|
||||
| `resolution`, action `steer` | `steer`, and `file_path` is in the other agent's working set | **pause**: stop editing that file until the other agent's diff lands | exit 2 with the reason (blocks this one tool call) |
|
||||
| `resolution`, action `steer` | `steer`, and `file_path` is not in the other agent's working set | **wait**: allowed, but told to keep to non-overlapping files | exit 0, message on stderr |
|
||||
| `resolution`, action `steer` | `steer`, and a `steer` target exists | **steer**: suggest the disjoint files or subtree the agent should move to | exit 0, message; exit 2 only if the edit is on the shared file |
|
||||
|
||||
The maneuver is deterministic: both agents read the same event, `hold` and `steer` are named in it, so the two sides never pick the same move. This is the TCAS coordination property and it is why the view computes right-of-way once, centrally, rather than each hook deciding.
|
||||
|
||||
`pause` blocks a single tool call, not the session. The agent sees the reason and can pick another file. Blocking is bounded by the event's `at`: an event older than the pane's poll interval times three is stale and the hook does not block on it.
|
||||
|
||||
## Priority
|
||||
|
||||
Right-of-way comes from the event (`action.hold`, `action.steer`). The view computes it as more progress, then earlier start, then stable id (`rightOfWay` in `scripts/lib/agent-proximity/distance.js`). The hook never recomputes it.
|
||||
|
||||
## Logging to the capsule
|
||||
|
||||
Every decision is one entry in the session's capsule journal (`scripts/lib/eval-harness/capsule.js`, hash-linked NDJSON):
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "tcas.decision",
|
||||
"event_id": "proximity.advisory:session-a|session-b:resolution",
|
||||
"session": "session-b",
|
||||
"tool": "Edit",
|
||||
"file": "src/api/users.js",
|
||||
"maneuver": "pause",
|
||||
"blocked": true,
|
||||
"risk": 1,
|
||||
"threshold": { "ta": 0.35, "ra": 0.7, "source": "static" },
|
||||
"at": "2026-09-11T20:01:03.000Z"
|
||||
}
|
||||
```
|
||||
|
||||
The capsule is the baseline counter for the 85 percent goal: rebase and merge-conflict triage incidents per week are counted from these entries plus `git rerere` and conflict markers, two weeks before and two weeks after the hook is on. No percentage is claimed before that.
|
||||
|
||||
## Where it plugs in
|
||||
|
||||
- **Claude Code**: a `PreToolUse` entry in `hooks/hooks.json` with matcher `Edit|Write|MultiEdit`, routed through `scripts/hooks/run-with-flags.js` so `ECC_HOOK_PROFILE` and `ECC_DISABLED_HOOKS` gate it. Script under `scripts/hooks/tcas-pre-edit.js`, helpers in `scripts/lib/control-pane/tcas.js`. Budget: under 200 ms, no network beyond loopback, exit 0 on any parse or fetch error.
|
||||
- **Codex**: no PreToolUse. The instruction-backed equivalent is the `proximity_steer` / `proximity_hold` message the tick already writes into the ECC2 `messages` table, surfaced on the next turn. `pause` degrades to a strong instruction.
|
||||
- **Hermes**: gateway hook on the tool-call path, same decision table, same capsule entry.
|
||||
|
||||
## Off switch and safety
|
||||
|
||||
- Disabled by default. On with `ECC_TCAS_HOOK=1` or the hook profile.
|
||||
- Read-only against the pane. It never writes to the sessions or messages tables.
|
||||
- No lease is acquired. Durable leases are slice (c), the worktree lease table in ecc2 `session/store.rs` next to `messages`; until then a `pause` is a per-call block, not a lock, and two hooks racing on the same file is possible but harmless (both see the same event and the same `steer`).
|
||||
- Fails open. Any error is exit 0 with a `[TCAS]` line on stderr.
|
||||
|
||||
## Tests to write with it
|
||||
|
||||
- Decision table: one test per row above, driven by a fixture event feed and a stdin payload.
|
||||
- Staleness: an event older than the window does not block.
|
||||
- Fail-open: unreachable pane, malformed JSON, missing session id.
|
||||
- Capsule: one entry per decision, hash chain intact, replay reproduces the same bytes.
|
||||
- Integration: two fake sessions with overlapping working sets, the lower-priority one gets exit 2 on the shared file and exit 0 on a disjoint file.
|
||||
|
||||
## Out of scope for (b)
|
||||
|
||||
Learned thresholds, closure-rate escalation, mesh mode, cross-machine airspace, the `x_sem`, `x_vec`, `x_freq` channels (slice g), and the lease table (slice c).
|
||||
@@ -0,0 +1,141 @@
|
||||
# ECC control-plane live view: `ecc.control-plane.view.v1`
|
||||
|
||||
Status: shipped with the control pane (`scripts/lib/control-pane/control-plane-view.js`). Read-only. Advisory only.
|
||||
|
||||
The view joins three things the repo already computes separately and serves them as one JSON document shaped as tasks, lanes and events, so another control plane (the Ito ops board, a Hermes or Codex reader, a hook) can consume it without knowing ECC internals.
|
||||
|
||||
| Input | Where it comes from |
|
||||
|---|---|
|
||||
| Sessions | `scripts/lib/control-pane/state.js`, the ECC2 `sessions` table |
|
||||
| Pairwise proximity | `scripts/lib/agent-proximity/` (noisy-OR over `x_tree`, `x_overlap`, `x_dep`) via `scripts/lib/control-pane/proximity.js` |
|
||||
| 2D projection | `scripts/lib/agent-proximity/projection.js` (rolling z-score, tails clipped at 2.5 / 97.5, PCA) |
|
||||
| Coordination inventory | `scripts/lib/coordination-inventory.js` (PR #3028): declared tasks and sessions, heartbeat freshness, lease conflicts |
|
||||
|
||||
## Endpoints
|
||||
|
||||
Served by `node scripts/control-pane.js` (loopback only, same Host and Origin gate as the rest of the pane):
|
||||
|
||||
| Route | Returns |
|
||||
|---|---|
|
||||
| `GET /control-plane` | Self-contained HTML page: 2D projection canvas, lanes and tasks, event feed. No external scripts. |
|
||||
| `GET /api/control-plane` | The full view document below. |
|
||||
| `GET /api/control-plane/events` | `{ schemaVersion, generatedAt, thresholds, events, counts }` only, for hooks and pollers. |
|
||||
|
||||
The server keeps one projection window per process. Both API routes share a snapshot cached for five seconds, and concurrent refresh requests are coalesced. Reads within that interval do not add samples. After expiry, the next read refreshes the snapshot once; idle intervals do not generate synthetic samples. Failed refreshes return errors rather than healthy empty data. The page rejects failed HTTP responses and invalid view envelopes and shows `offline`. Options on `createControlPaneServer`: `projection` (`windowSize`, `clipPercentiles`), `viewOptions` (`thresholds`, `manifest`, `channelWeights`, `minWindowForZscore`), `proximityOptions` (passed to the scan).
|
||||
|
||||
## Document
|
||||
|
||||
```json
|
||||
{
|
||||
"schemaVersion": "ecc.control-plane.view.v1",
|
||||
"generatedAt": "2026-09-11T20:01:00.000Z",
|
||||
"source": { "snapshotSchema": "ecc.control-pane.snapshot.v1", "repoRoot": "...", "dbPath": "..." },
|
||||
"thresholds": { "ta": 0.35, "ra": 0.7, "source": "static" },
|
||||
"lanes": [ { "id": "harness:codex", "label": "codex", "kind": "harness", "taskIds": ["session-a"] } ],
|
||||
"tasks": [ { "...": "see Task" } ],
|
||||
"pairs": [ { "...": "see Pair" } ],
|
||||
"events": [ { "...": "see Event" } ],
|
||||
"projection": { "...": "see Projection" },
|
||||
"inventory": { "...": "see Inventory" },
|
||||
"counts": { "lanes": 1, "tasks": 1, "agents": 1, "pairs": 0, "events": 0, "advisories": 0, "resolutions": 0 },
|
||||
"limits": [ "..." ]
|
||||
}
|
||||
```
|
||||
|
||||
### Task
|
||||
|
||||
One task per session. A session with no changed files is still a task; it has no projection point and no pairs.
|
||||
|
||||
| Field | Meaning |
|
||||
|---|---|
|
||||
| `id` | Session id, unchanged. |
|
||||
| `lane` | Lane id this task belongs to. |
|
||||
| `label` | Session task text, or the id. |
|
||||
| `harness`, `agentType`, `state`, `pid` | From the session row. |
|
||||
| `worktree` | `{ path, branch, base }` or `null`. |
|
||||
| `heartbeatAt`, `updatedAt` | ISO timestamps or `null`. |
|
||||
| `workingSet` | `{ fileCount, files }`: the worktree diff against its base. |
|
||||
| `projection` | `{ point, pairs, maxRisk }` where `point` is `[x, y]` or `null`. `point` is the risk-weighted centroid of the task's pair points in PCA space. |
|
||||
| `inventory` | `{ id, heartbeat, process, authority: "declared-only" }`. `id` is the sanitized identifier used in the inventory manifest; `heartbeat` and `process` are the #3028 observations. |
|
||||
|
||||
### Lane
|
||||
|
||||
A grouping of tasks. Precedence: `task-group` (session `task_group`), then `project`, then `harness`. Ids are prefixed (`group:`, `project:`, `harness:`) so a consumer can tell the kinds apart without reading `kind`.
|
||||
|
||||
### Pair
|
||||
|
||||
One row per agent pair from the airspace scan (only sessions with edits participate).
|
||||
|
||||
| Field | Meaning |
|
||||
|---|---|
|
||||
| `a`, `b` | Session ids. |
|
||||
| `risk`, `level` | Noisy-OR risk and the scan's level (`clear`, `advisory`, `resolution`) at the scan's thresholds. |
|
||||
| `channels` | Raw `{ x_tree, x_overlap, x_dep }` in [0, 1]. |
|
||||
| `normalized` | The same after z-score, clip and map-back, or equal to `channels` while the window is cold. |
|
||||
| `point` | `[pc1, pc2]` PCA scores. |
|
||||
|
||||
### Event
|
||||
|
||||
Something an operator or a hook may act on. Ids are deterministic across polls so a consumer can dedupe.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "proximity.advisory:session-a|session-b:resolution",
|
||||
"kind": "proximity.advisory",
|
||||
"level": "resolution",
|
||||
"severity": "critical",
|
||||
"at": "2026-09-11T20:01:00.000Z",
|
||||
"subject": { "a": "session-a", "b": "session-b", "aLabel": "...", "bLabel": "..." },
|
||||
"risk": 1,
|
||||
"distance": 0,
|
||||
"channels": { "x_tree": 1, "x_overlap": 1, "x_dep": 0 },
|
||||
"threshold": { "ta": 0.35, "ra": 0.7, "crossed": "ra", "source": "static" },
|
||||
"action": { "type": "steer", "steer": "session-b", "hold": "session-a" },
|
||||
"message": "Resolution advisory: session-b steers, session-a holds (risk 100%, static threshold 0.7)."
|
||||
}
|
||||
```
|
||||
|
||||
| Kind | Levels | Action types | Source |
|
||||
|---|---|---|---|
|
||||
| `proximity.advisory` | `traffic` (risk at or above `ta`), `resolution` (at or above `ra`) | `transmit` (both agents share intent), `steer` (`steer` moves, `hold` keeps course) | Every pair link, evaluated against the view's thresholds. Right-of-way: more progress, then earlier start, then stable id. |
|
||||
| `inventory.lease-conflict` | `conflict` | `review` | #3028 `leaseConflicts`. Declared-only, never a lock. |
|
||||
|
||||
Thresholds are static per view (`source: "static"`). A learned threshold, closure-rate escalation, and the `pause` and `wait` maneuvers are slice (b), see `TCAS-HOOK.md`.
|
||||
|
||||
### Projection
|
||||
|
||||
```json
|
||||
{
|
||||
"method": "pca",
|
||||
"channels": ["x_tree", "x_overlap", "x_dep"],
|
||||
"weights": { "x_tree": 0.25, "x_overlap": 1, "x_dep": 0.9 },
|
||||
"normalization": "zscore-clipped",
|
||||
"window": { "samples": 12, "percentiles": [2.5, 97.5], "channels": [ { "channel": "x_tree", "mean": 0.39, "stddev": 0.42, "clipLow": -0.92, "clipHigh": 1.45 } ] },
|
||||
"pca": { "loadings": [ { "x_tree": 0.12, "x_overlap": 0.87, "x_dep": -0.47 }, { "...": "..." } ], "explainedVariance": [0.6, 0.39] },
|
||||
"agents": [ { "agentId": "session-a", "point": [0.18, 0.41], "pairs": 3, "maxRisk": 1 } ]
|
||||
}
|
||||
```
|
||||
|
||||
Pipeline per poll: every pair's channel vector is pushed into a rolling window (default 512 samples). Once the window holds at least 8 samples, each channel is z-scored against the window, clipped to the window's 2.5th and 97.5th percentile (in z units), mapped back to [0, 1], multiplied by the static channel weight, and the weighted matrix goes through PCA (Jacobi on the 3x3 covariance). Below 8 samples the raw channel values are used and `normalization` says `raw`. A channel with zero variance maps to 0.5. Degenerate inputs (fewer than two pairs, zero total variance) give zero scores, never NaN.
|
||||
|
||||
The projection is a display. It never changes `risk`, the advisory level, or right-of-way.
|
||||
|
||||
### Inventory
|
||||
|
||||
The #3028 report with the per-task rows folded into `tasks[].inventory`. Kept at the top level: `status` (`ok` or `unavailable` with `reason`), `truncated` (more than 64 sessions), `observedAt`, `mode: "read-only"`, `activity`, `leaseConflicts`, `warnings`, `coverage`, `limits`. The manifest is built from the live sessions (ids sanitized to the inventory alphabet, paths from the working set, heartbeat from the session row, declared session status `open` for running/pending/idle, `closed` for completed/failed/stopped). An external manifest (`viewOptions.manifest`) can add `goals`, `leases`, `repositories` and extra `tasks`; the inventory then reports lease conflicts and goal activity for them.
|
||||
|
||||
## Reuse in the Ito ops control plane
|
||||
|
||||
The shape to copy is `task`, `lane`, `event`:
|
||||
|
||||
- a **task** has an `id`, a `lane`, a `state`, an optional position, and an observation block whose `authority` says how much to trust it;
|
||||
- a **lane** is a named group with ordered `taskIds`;
|
||||
- an **event** has a stable `id`, a `kind`, a `level`, a `severity`, an `at`, a `subject`, an `action` with a `type`, and a human `message`.
|
||||
|
||||
Nothing in the shape is ECC-specific except the event kinds. An ops board that renders lanes of tasks and a feed of events can render this document as-is, and can emit its own kinds (`deal.stalled`, `bridge.down`) into the same feed.
|
||||
|
||||
## What this does not do
|
||||
|
||||
- No leases are acquired, no agent is paused or steered. Consumers act; the view reports.
|
||||
- No conflict-reduction percentage is claimed. The 85 percent goal in the push plan is measured two weeks before and after slice (b), not here.
|
||||
- No semantic, call-graph or frequency channel yet (slice (g)). PCA picks new channels up automatically when they land in the scan.
|
||||
@@ -4,8 +4,8 @@
|
||||
|
||||
|
||||
|
||||
[](https://github.com/affaan-m/ECC/stargazers)
|
||||
[](https://github.com/affaan-m/ECC/network/members)
|
||||
[](https://github.com/affaan-m/ECC)
|
||||
[](https://github.com/affaan-m/ECC/forks)
|
||||
[](https://github.com/affaan-m/ECC/graphs/contributors)
|
||||
[](https://www.npmjs.com/package/ecc-universal)
|
||||
[](https://www.npmjs.com/package/ecc-agentshield)
|
||||
|
||||
@@ -33,6 +33,30 @@ one harness's hook support.
|
||||
- Procedural memory remains in rules and instincts, subject to their existing
|
||||
promotion and validation gates.
|
||||
|
||||
### Retrieval completeness and current state
|
||||
|
||||
A bounded scan can be incomplete even when it has found a matching ID. Direct
|
||||
reads reject truncated scans and scans containing invalid or unreadable memory
|
||||
documents before claiming absence, uniqueness or complete backlinks. The core
|
||||
error is `ECC_MEMORY_INCOMPLETE`; local MCP returns the safe tool error
|
||||
`MEMORY_READ_INCOMPLETE`. No partial memory content is returned in that case.
|
||||
Search retains its existing diagnostics so callers can inspect partial results
|
||||
without interpreting them as a complete inventory. Entries excluded by the
|
||||
existing hidden-file or symlink policy remain excluded; this does not bypass
|
||||
filesystem safety or imply an atomic snapshot across concurrent edits.
|
||||
|
||||
Failing a direct read because another document is malformed is an intentional
|
||||
tradeoff: the operator must repair the authorized vault before relying on a
|
||||
complete ID lookup. Use the existing doctor to inspect problems. Do not expand
|
||||
scope or permissions to make a failed lookup pass.
|
||||
|
||||
Supersession links are references, not automatic revocations. The existing
|
||||
operator-reviewed status field controls active search; a direct read remains
|
||||
available for explicit historical inspection once the scan is complete. Evidence
|
||||
matching and lexical relevance do not establish current truth, authenticated
|
||||
authorship or authority to execute actions. Those checks belong to the consuming
|
||||
workflow, with original evidence retained when a fact changes.
|
||||
|
||||
### Threat boundary
|
||||
|
||||
The first-release runtime defends against hostile vault documents, stable
|
||||
|
||||
+7
-7
@@ -50,13 +50,13 @@ Este es un **plugin de IA para codificación listo para producción** que propor
|
||||
## Orquestación de Agentes
|
||||
|
||||
Usa agentes proactivamente sin prompt del usuario:
|
||||
- Solicitudes de features complejas → **planner**
|
||||
- Código recién escrito/modificado → **code-reviewer**
|
||||
- Corrección de bug o nueva feature → **tdd-guide**
|
||||
- Decisión arquitectónica → **architect**
|
||||
- Código sensible a la seguridad → **security-reviewer**
|
||||
- Bucles autónomos / monitoreo de bucles → **loop-operator**
|
||||
- Confiabilidad y costo de la configuración del harness → **harness-optimizer**
|
||||
- Solicitudes de features complejas → **ecc:planner**
|
||||
- Código recién escrito/modificado → **ecc:code-reviewer**
|
||||
- Corrección de bug o nueva feature → **ecc:tdd-guide**
|
||||
- Decisión arquitectónica → **ecc:architect**
|
||||
- Código sensible a la seguridad → **ecc:security-reviewer**
|
||||
- Bucles autónomos / monitoreo de bucles → **ecc:loop-operator**
|
||||
- Confiabilidad y costo de la configuración del harness → **ecc:harness-optimizer**
|
||||
|
||||
Usa ejecución paralela para operaciones independientes — lanza múltiples agentes simultáneamente.
|
||||
|
||||
|
||||
+3
-3
@@ -4,13 +4,13 @@
|
||||
|
||||
|
||||
|
||||
[](https://github.com/affaan-m/ECC/stargazers)
|
||||
[](https://github.com/affaan-m/ECC/network/members)
|
||||
[](https://github.com/affaan-m/ECC)
|
||||
[](https://github.com/affaan-m/ECC/forks)
|
||||
[](https://github.com/affaan-m/ECC/graphs/contributors)
|
||||
[](https://www.npmjs.com/package/ecc-universal)
|
||||
[](https://www.npmjs.com/package/ecc-agentshield)
|
||||
[](https://github.com/marketplace/ecc-tools)
|
||||
[](LICENSE)
|
||||
[](../../LICENSE)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,29 +2,36 @@
|
||||
|
||||
## Agentes Disponibles
|
||||
|
||||
Ubicados en `~/.claude/agents/`:
|
||||
Los agentes de ECC se distribuyen con el plugin `ecc@ecc`, no en `~/.claude/agents/`.
|
||||
Se invocan a través de la herramienta Agent con un `subagent_type` con ámbito de plugin:
|
||||
|
||||
```text
|
||||
Agent(subagent_type: "ecc:planner", prompt: "...")
|
||||
```
|
||||
|
||||
| Agente | Propósito | Cuándo Usar |
|
||||
|--------|-----------|-------------|
|
||||
| planner | Planificación de implementación | Features complejas, refactoring |
|
||||
| architect | Diseño de sistemas | Decisiones arquitectónicas |
|
||||
| tdd-guide | Desarrollo guiado por pruebas | Nuevas features, corrección de bugs |
|
||||
| code-reviewer | Revisión de código | Después de escribir código |
|
||||
| security-reviewer | Análisis de seguridad | Antes de los commits |
|
||||
| build-error-resolver | Corrección de errores de build | Cuando el build falla |
|
||||
| e2e-runner | Testing E2E | Flujos de usuario críticos |
|
||||
| refactor-cleaner | Limpieza de código muerto | Mantenimiento de código |
|
||||
| doc-updater | Documentación | Actualización de docs |
|
||||
| rust-reviewer | Revisión de código Rust | Proyectos Rust |
|
||||
| harmonyos-app-resolver | Desarrollo de apps HarmonyOS | Proyectos HarmonyOS/ArkTS |
|
||||
| ecc:planner | Planificación de implementación | Features complejas, refactoring |
|
||||
| ecc:architect | Diseño de sistemas | Decisiones arquitectónicas |
|
||||
| ecc:tdd-guide | Desarrollo guiado por pruebas | Nuevas features, corrección de bugs |
|
||||
| ecc:code-reviewer | Revisión de código | Después de escribir código |
|
||||
| ecc:security-reviewer | Análisis de seguridad | Antes de los commits |
|
||||
| ecc:build-error-resolver | Corrección de errores de build | Cuando el build falla |
|
||||
| ecc:e2e-runner | Testing E2E | Flujos de usuario críticos |
|
||||
| ecc:refactor-cleaner | Limpieza de código muerto | Mantenimiento de código |
|
||||
| ecc:doc-updater | Documentación | Actualización de docs |
|
||||
| ecc:rust-reviewer | Revisión de código Rust | Proyectos Rust |
|
||||
| ecc:harmonyos-app-resolver | Desarrollo de apps HarmonyOS | Proyectos HarmonyOS/ArkTS |
|
||||
|
||||
Para el roster completo de 68 agentes, ver `/ecc:ecc-guide`.
|
||||
|
||||
## Uso Inmediato de Agentes
|
||||
|
||||
Sin necesidad de prompt del usuario:
|
||||
1. Solicitudes de features complejas - Usar el agente **planner**
|
||||
2. Código recién escrito/modificado - Usar el agente **code-reviewer**
|
||||
3. Corrección de bug o nueva feature - Usar el agente **tdd-guide**
|
||||
4. Decisión arquitectónica - Usar el agente **architect**
|
||||
1. Solicitudes de features complejas - Usar el agente **ecc:planner**
|
||||
2. Código recién escrito/modificado - Usar el agente **ecc:code-reviewer**
|
||||
3. Corrección de bug o nueva feature - Usar el agente **ecc:tdd-guide**
|
||||
4. Decisión arquitectónica - Usar el agente **ecc:architect**
|
||||
|
||||
## Ejecución Paralela de Tareas
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user