exeris-subsystem-specialist

name: exeris-subsystem-specialist description: 'Subsystem-focused PR review for Exeris Kernel using one skill with modes: bootstrap, memory, crypto, transport, persistence, events, flow, http, security, config. Use when you want a targeted subsystem review without creating many separate agents.' argument-hint: 'Mode (bootstrap|memory|crypto|transport|persistence|events|flow|http|security|config) + PR scope/files + review goal' user-invocable: true disable-model-invocation: false

Exeris Subsystem Specialist

Purpose

Provide one lightweight, mode-driven subsystem review skill instead of many dedicated agents.

This skill keeps one shared Exeris philosophy while switching to subsystem-specific checks via mode.

Supported Modes

• bootstrap
• memory
• crypto
• transport
• persistence
• events
• flow
• http
• security
• config

Invocation Pattern

Use a mode-first subprompt, for example:

• Review this as Transport subsystem
• Review this as Memory subsystem
• Review this as Security subsystem

If mode is not explicit, infer from changed files. If still ambiguous, ask for one mode before continuing.

Canon to Load Before Review

Always load:

• docs/architecture.md
• docs/whitepaper.md
• docs/performance-contract.md
• docs/modules/01-spi.md
• docs/modules/02-core.md
• docs/modules/03-community.md
• docs/modules/04-enterprise.md
• docs/modules/05-tck.md
• related ADRs in docs/adr

Then load exactly one subsystem contract based on selected mode:

• bootstrap -> docs/subsystems/bootstrap.md
• memory -> docs/subsystems/memory.md
• crypto -> docs/subsystems/crypto.md
• transport -> docs/subsystems/transport.md
• persistence -> docs/subsystems/persistence.md
• events -> docs/subsystems/events.md
• flow -> docs/subsystems/flow.md
• http -> docs/subsystems/http.md
• security -> docs/subsystems/security.md
• config -> docs/subsystems/config.md

Mode Workflow

1. Select mode

   • Explicit mode from user wins.
   • Otherwise infer from changed symbols/files.
   • If multiple modes compete, choose primary mode and list secondary impacts.

2. Build review lens for selected mode

   • Extract contract invariants, lifecycle semantics, performance limits, and error model from subsystem doc.
   • Extract cross-module boundaries from module docs and ADRs.

3. Run focused checks

   • Contract correctness: changed behavior must match subsystem contract semantics.
   • Boundary integrity: no SPI leakage, no Core driver leakage, no The Wall breach.
   • Performance law: no regressions against No Waste Compute constraints.
   • TCK implications: contract changes require executable TCK impact analysis and bindings.

4. Run mode-specific deep checks

   • bootstrap: startup lifecycle ordering, bootstrap events, readiness/latency gates.
   • memory: allocator ownership, leak safety, ref-count discipline, O(1) alloc-release behavior.
   • crypto: handshake lifecycle, zero-alloc constraints, native boundary hygiene, error-code contracts.
   • transport: connection/stream lifecycle, backpressure/load-shed semantics, zero-copy data path.
   • persistence: transaction boundaries, rollback semantics, concurrency invariants, consistency contract.
   • events: delivery semantics, ordering/idempotency expectations, provider-switching contract behavior.
   • flow: scheduling and park-wake semantics, latency/throughput invariants, state-machine correctness.
   • http: provider/server/client/handler/exchange contract conformance at SPI boundary.
   • security: context propagation, identity/authorization invariants, isolation and auditability guarantees.
   • config: schema and validation semantics, deterministic resolution/override precedence, boot-time safety.

5. Decision and report

   • Output verdict: APPROVE, CONDITIONAL, REJECT.
   • Map findings to mode contract clause, impacted symbols, runtime risk, and minimal corrective action.

Decision Logic

• APPROVE: selected mode contract is fully preserved and no cross-cutting guardrail is violated.
• CONDITIONAL: localized drift with clear remediation and no fundamental contract break.
• REJECT: subsystem contract violation, boundary breach, performance law breach, or missing TCK implications for contract changes.

Completion Criteria

A review is complete only if all are true:

• Mode selection is explicit and justified.
• Selected subsystem doc was loaded and used as primary contract source.
• Cross-cutting checks were run (architecture, performance, TCK).
• Mode-specific deep checks were run and evidenced.
• Verdict and required actions are precise and minimal.

Review Output Template

1. Scope analyzed (mode, files, symbols)
2. Contract findings (selected subsystem)
3. Boundary findings (SPI/Core/The Wall)
4. Performance findings (No Waste Compute)
5. TCK findings (contract test implications)
6. Verdict (APPROVE | CONDITIONAL | REJECT)
7. Required actions (minimal root-cause fixes)

Non-Negotiable Rules

• One review, one primary mode, one contract source of truth.
• No subsystem review without loading its subsystem doc.
• No contract-changing PR accepted without TCK implications analysis.
• No violation of architecture boundaries or performance contract under any mode.