axum-harness

Maintains contracts, schema, shared protocol, and generated contract artifacts. Owns packages/contracts/**, docs/contracts/**, verification/contract/**. Use when changing shared DTOs, event schemas, error shapes, contract docs, generated protocol artifacts, or contract drift checks. Runs type generation, detects contract drift, and enforces contract change workflow.

Top-level orchestrator. Reads user intent, audits touched paths, routes tasks to domain subagents, dispatches in dependency order, converges results, and preserves repository boundaries. Use when work spans multiple ownership boundaries, touches agent/docs/tooling control plane, or needs path routing and gate selection. Never writes business logic, endpoint handlers, or domain code.

Maintains platform model, topology, generators, validators, infra declarations, and ops runbooks. Owns platform/model/**, platform/schema/**, infra/**, ops/**. Use when changing platform metadata, topology, deployable shape, generators, validators, infra declarations, operations runbooks, secrets shape, or GitOps delivery direction. Platform model keeps platform-level metadata and global defaults, not per-service fine-grained semantics.

Maintains servers, handlers, routes, middleware, and sync entrypoints. Owns servers/bff/**, servers/gateway/**, servers/internal-rpc/**. Use when changing HTTP handlers, routes, middleware, API composition, server entrypoints, request/response adaptation, or protocol integration. Does protocol adaptation and API composition only — never owns core domain logic or long-running transaction semantics.

Maintains services, domain logic, application layer, policies, ports, and service-local distributed semantics in services/<name>/model.yaml. Owns services/**, fixtures/**, verification/** (service-level). Services are pure libraries — no main.rs, no HTTP server, no message consumer loops. Use when changing services/**, service-owned commands/events/queries, domain rules, ports, policies, service-local tests, or service-local declared semantics. Never implements infrastructure adapters or process entry points.

Maintains workers, async executors, projectors, schedulers, and sync coordinators. Owns workers/**, verification/resilience/**, verification/topology/**, verification/replay/**. Use when changing workers/**, replay paths, async execution, projection behavior, checkpointing, retry, dedupe, or worker recovery evidence. Every worker must declare idempotency, retry, checkpoint/replay, and recovery behavior explicitly.

Finds architecture deepening opportunities using seams, module depth, deletion tests, evidence hierarchy, and repository ownership boundaries. Use when reviewing architecture, reducing coupling, improving testability, or evaluating whether a module, trait, adapter, worker, service, or boundary is too shallow.

Alignment workflow for ambiguous harness plans, architecture choices, scope, and terminology. Use when requirements are fuzzy, terms are overloaded, a decision affects multiple ownership boundaries, or the user asks to stress-test a plan before implementation.

Creates, edits, or reviews repository agent skills with triggerable descriptions, progressive disclosure, and boundary-safe instructions. Use when adding, editing, or reviewing .agents/skills/** or workflow skill documentation.

Always-on backend engineering quality kernel for Rust/Axum harness work. Use when changing or reviewing backend services, servers, workers, contracts, repo-tools, platform-facing backend metadata, or backend documentation. Guides invariant-first design, boundary discipline, evidence language, and template-quality code judgment without overriding ownership skills.

Disciplined diagnosis workflow for failing gates, regressions, flaky behavior, performance regressions, and suspicious backend/runtime behavior. Use when the user reports a bug, broken invariant, failing command, failing test, or asks to diagnose/debug a problem.

Vertical-slice test-driven workflow for backend harness features and bug fixes. Use when adding or changing service, server, worker, contract, or repo-tool behavior, or when the user asks for TDD, red-green-refactor, or test-first implementation.

Explains an unfamiliar repository area one layer up using ownership, callers, seams, evidence level, and gate context. Use when the user or agent is unfamiliar with a code area, needs a map before editing, or asks how a module fits into the harness.