How do their APIs compare?

This gives a much clearer picture. Let me lay out the actual comparison now.

API comparison: expressjs/express vs affaan-m/ecc

These two projects are not really comparable API-for-API — they solve different kinds of problems — but here's what the evidence shows on each side.

expressjs/express — an HTTP framework API

Its "API" is the classic request/response/middleware surface:

• Routing/mounting: app.get(), app.use(), path-scoped middleware (e.g. API-key validation mounted only on /api) [examples/web-service/index.js:L29-L38], parameterized routes (/user/:name/repos) [examples/web-service/index.js:L79-L86].
• Middleware arity convention: 3-arg (req, res, next) middleware vs. 4-arg (err, req, res, next) error-handling middleware, dispatched differently by Express's internals when next(err) is called [examples/web-service/index.js:L92-L102].
• Response methods on lib/response.js: res.send(), res.json() (backed by an internal stringify() helper supporting replacer, spaces, and safe-escaping of <>&) [lib/response.js:L231-L240, lib/response.js:L1026-L1049], and res.links() for building Link headers, including multi-value rel arrays [lib/response.js:L97-L109].
• Error convention: plain Error objects with a .status property, created via a small error(status, msg) helper and passed through next(err) [examples/web-service/index.js:L15-L19].

This is a stable, decades-familiar Node.js server API: you compose handlers/middleware and call methods on req/res.

affaan-m/ecc — not an HTTP API; it's an agent-harness system with CLI/config/skill surfaces

There's no req/res-style API here. Instead, ecc exposes several distinct kinds of "API" surface:

• Environment/config surface: hook strictness is controlled via an env var like ECC_HOOK_PROFILE=standard [README.zh-CN.md:L223-L225].
• CLI surface (ECC 2.0 alpha, Rust): a control layer under ecc2/ exposing commands dashboard, start, sessions, status, stop, resume, and daemon [README.zh-CN.md:L87-L95].
• Naming/identifier surface: three distinct public identifiers that are not interchangeable — the GitHub repo affaan-m/ECC, the Claude marketplace/plugin id ecc@ecc, and the npm package ecc-universal [README.md:L351-L360].
• Python template registry API: an internal validator _validate_template_input(name, template=None) enforces that template names/content are non-empty strings before mutating a template registry [src/llm/prompt/templates/init.py:L9-L15] — this suggests a register_template-style API elsewhere in src/llm/prompt/templates/.
• Behavioral/architectural contracts (from AGENTS.md and RULES.md, which act like API-design guidelines for contributors rather than runtime APIs): immutability (return new objects, never mutate) [AGENTS.md:L83], small files/functions (200–400 lines typical, <50-line functions) [AGENTS.md:L85-L94], mandatory input validation at system boundaries [AGENTS.md:L89], and hard rules against leaking secrets/tokens or bypassing validation hooks [RULES.md:L13-L15].

Bottom line

• express exposes a runtime HTTP API (routing, middleware, response serialization) meant to be consumed by other Node.js code at request-time.
• ecc exposes a mix of CLI commands (ecc2 Rust binary), environment-variable configuration, package/plugin identifiers for distribution, and internal validation helpers (like the Python template registry) — it's oriented around orchestrating "agent harness" behavior (skills, memory, hooks) rather than serving HTTP requests. Its coding-style docs (AGENTS.md, RULES.md) function more like an internal API-design contract for contributors than a documented public API.

If you want, I can dig further into the ecc2/ Rust CLI commands themselves or the full template-registry API in `src/llm/prompt