exeris-spring-runtime

Detect documentation and ADR drift against runtime ownership and mode reality. Classifies drift (NO_ACTION / MINOR_DOC_UPDATE / DOCS_UPDATE_REQUIRED / ADR_IMPACT / NEW_ADR_REQUIRED), names affected docs, and recommends merge timing for the docs/ADR delta.

Prevent Spring leakage into kernel boundaries and preserve The Wall. Verifies no Spring imports/types/annotations in kernel SPI/Core touchpoints, no framework-coupled contracts in Exeris kernel abstractions, no bypass of canonical Exeris provider discovery, and no kernel API changes that assume servlet/reactive/JDBC framework runtime.

Prevent confusion between Pure Mode and Compatibility Mode in code, tests, and docs. Flags features that lack a mode label, compatibility behavior that leaks into the pure path, and docs that claim pure semantics while implementation is compatibility-driven.

Enforce module-responsibility boundaries across exeris-spring-boot-autoconfigure, exeris-spring-runtime-web/-tx/-data/-actuator. Flags web/runtime logic in autoconfigure, tx semantics in actuator, persistence ownership in web, compatibility sludge spread across modules, and runtime orchestration moved into the boot layer.

Check whether a change preserves the runtime-ownership truth (Spring = application framework, Exeris = runtime owner). Flags ownership inversion to servlet/reactive/JDBC-first runtime, split-brain lifecycle, fake host-runtime claims, and hidden fallback ownership outside Exeris.

Produce a minimal, risk-aware execution order across exeris-spring-runtime agents — choose the primary agent, ordered secondary handoffs, a 3-5 step plan, validation gates, and the single best next action. Use after task-classifier has labelled the work.

Review request-path integration overhead in Spring bridges — wrapper/DTO churn, request/response copy inflation, codec layering overhead, reflection-heavy hot paths, context propagation cost, and hidden fallback overhead to legacy runtime path. Use when a change materially affects the request path.

Classify an incoming exeris-spring-runtime task into one primary class (ARCHITECTURE / INTEGRATION_IMPLEMENTATION / VERIFICATION / DOCS_ADR / PERFORMANCE / MULTI_DOMAIN) plus mode impact (PURE_MODE / COMPATIBILITY_MODE / MIXED / UNCLEAR), with a short rationale and a confidence rating. Use as the first triage step before routing.

Plan verification depth (unit / module-integration / runtime-integration / architecture-guard / optional performance) based on change risk and architecture impact. Highlights merge-blocking gaps in evidence — particularly missing host-runtime ownership proofs and missing mode distinctions.