| name | exeris-architect-guardrails |
| description | Architectural PR review for Exeris Kernel. Use for every PR review to enforce docs/modules, docs/subsystems, ADR alignment, The Wall boundaries, SPI blindness, Core isolation, and dependency graph integrity. |
| argument-hint | PR scope, changed modules/files, and intended architectural impact |
| user-invocable | true |
| disable-model-invocation | false |
Exeris Architect Guardrails
Purpose
Run a strict architectural review for Exeris Kernel changes so every PR remains aligned with:
docs/modules/*.md
docs/subsystems/*.md
docs/adr/*.md
- The Wall boundaries and established open-core structure
This skill is mandatory for PR reviews that touch architecture, module boundaries, subsystem contracts, or dependency wiring.
When to Use
- Any PR review in Exeris Kernel (default)
- Any change touching SPI/Core/Community/Enterprise/TCK modules
- Any change introducing or modifying interfaces, providers, adapters, transport/security/persistence internals
- Any refactor that can alter dependency direction or module layering
Required Inputs
- PR diff or changed file list
- Affected modules and subsystems
- Stated intent of the change (what boundary or behavior it modifies)
Review Procedure
-
Load architectural canon first
- Read relevant module contracts in
docs/modules/*.md.
- Read impacted subsystem contracts in
docs/subsystems/*.md.
- Read all potentially related ADRs in
docs/adr/*.md.
- Treat accepted ADRs as binding constraints, not suggestions.
-
Boundary audit: The Wall
- Verify SPI remains implementation-blind.
- Verify Core remains orchestration-only and does not leak concrete drivers.
- Verify implementation-specific concerns stay in Community/Enterprise layers.
-
Leak detection (hard fail checks)
- Reject if SPI references or implies
io_uring, OpenSSL, QUIC, epoll, OS-native structs, or provider-native flags.
- Reject if Core exposes or depends on implementation transport/crypto/storage driver details.
- Reject if public contracts are polluted by provider-specific semantics.
-
Dependency graph integrity
- Confirm no dependency inversion against module architecture.
- Confirm no new edge that makes upper-level contracts depend on lower-level implementations.
- Confirm no back-reference from SPI/Core into Enterprise internals.
-
ADR compliance gate
- Reject proposals that effectively roll back accepted ADR decisions.
- Reject creation of new modules/structure when an ADR already fixes canonical structure.
- If proposing an exception, require explicit new ADR rather than silent deviation.
-
Decision and report
- Produce one of:
APPROVE, CONDITIONAL, REJECT.
- For each issue, map finding -> violated document/decision -> required corrective action.
Decision Logic
- APPROVE: No boundary leaks, no graph violations, no ADR conflicts.
- CONDITIONAL: Fixable architecture drift with clear remediation and no ADR rollback intent.
- REJECT: Any The Wall breach, SPI implementation leak, Core driver leak, dependency inversion, or ADR rollback.
Completion Criteria
A review is complete only if all are true:
- Every affected module/subsystem was checked against corresponding docs.
- SPI/Core/implementation boundaries were explicitly validated.
- Dependency graph direction was validated for changed edges.
- ADR impact was analyzed and documented.
- Final verdict and remediation list were provided.
Review Output Template
Use this structure in PR feedback:
- Scope analyzed (modules, subsystems, ADRs reviewed)
- Boundary findings (SPI/Core/The Wall)
- Dependency findings (new/changed edges)
- ADR findings (compliant/conflicting)
- Verdict (
APPROVE / CONDITIONAL / REJECT)
- Required actions (precise and minimal)
Non-Negotiable Rules
- Never allow SPI to know implementation details.
- Never allow Core to leak concrete driver logic.
- Never reverse intended dependency direction.
- Never undo accepted ADR structure without a new ADR.
- Prefer minimal corrective changes that restore architectural integrity at the root cause.