exeris-platform

One-pass sweep of all five platform contracts for a broad or multi-module change — no-parallel-metamodel, LSP wire surface, idempotent write-back, open-core boundary, and frontend projection — returning a single consolidated verdict. Use on a large PR, a pre-merge gate, or any change whose blast radius crosses studio-backend, exeris-platform-lsp, and exeris-studio-frontend at once, when running the reviews individually would be slow or easy to forget one.

Validate a change that spans the Maven reactor and the npm frontend (cross-build). Use whenever a change touches both Java modules (exeris-platform-lsp / exeris-studio-backend) and exeris-studio-frontend, alters a contract surface the frontend consumes (an `exeris/*` LSP method or its wire shape), or bumps a cross-repo `eu.exeris:*` / `eu.exeris.tooling:*` dependency. Confirms both builds stay green and the wire contract matches on both sides before the change is called done.

Pick the right decision-document shape BEFORE drafting — Research vs RFC vs ADR — per the exeris-docs templates and the single ecosystem-wide ADR namespace. Use when asked to "write an ADR", "document this decision", "draft an RFC", or "write a research note" for the platform, especially when upstream measurement or option comparison is still missing. Enforces reserve-number-first discipline for true ADRs and steers premature ADRs back to Research/RFC.

Ensure the Studio frontend PROJECTS the canonical DomainMetadata into an ephemeral view-model rather than PERSISTING a parallel shape, and never writes `.java` sources directly. Use on any exeris-studio-frontend (Angular + embedded React) change that adds a model/store/state type, a service that holds entity/field/relation shape, or any file-write path. Complements no-parallel-metamodel-review, which guards backend/LSP rather than the frontend.

Deep, evidence-gathering review that the same `MutationOp` applied twice converges to identical on-disk state. Finds the write-path diff itself, checks writer routing, import/line/whitespace stability, and the round-trip test, then issues a verdict. Use whenever the `exeris/applyMutation` path, the `exeris-sdk-source-model` writer integration, a new mutation kind, or import/whitespace/line-number-sensitive emission changes. (For a quick inline audit with a diff in hand, the `/idempotent-writeback-check` command is the lighter path.)

Deep, evidence-gathering review of the LSP wire surface — finds the diff itself, audits namespacing, SDK-owned shapes, and transport parity, and issues a verdict. Use whenever a custom `exeris/*` method is added/removed/renamed, the wire shape of `MutationOp`/`MutationResult` changes, stdio vs WebSocket transport could diverge, or a method is consumed by `exeris-ai-bridge`. (For a quick inline audit with a diff in hand, the `/lsp-protocol-purity` command is the lighter path.)

Deep, evidence-gathering review that detects parallel-metamodel regression in `exeris-studio-backend` or `exeris-platform-lsp` — finds the diff itself, classifies each new type as projection vs persistence, and issues an APPROVE / CONDITIONAL / REJECT verdict. Use on any change that adds a record/class to those modules, adds a backend REST/HTTP endpoint, or is motivated by "store workspace entities" / "track project structure". (For a quick inline audit with a diff in hand, the `/no-parallel-metamodel-check` command is the lighter path.)

Deep, evidence-gathering review of the open-core boundary — finds the diff itself, distinguishes an extension point (open-core OK) from a concrete premium implementation (belongs in `exeris-platform-enterprise`), and issues a verdict. Use whenever a change proposes or touches a feature with a premium counterpart — multi-env promotion, RBAC, approval workflows, audit dashboards, multi-tenant/org concepts. (For a quick inline audit with a diff in hand, the `/open-core-boundary` command is the lighter path.)

Turn a classified exeris-platform task into a risk-ordered execution plan — primary agent, ordered secondary handoffs, step sequence, must-pass validation gates, and the minimal next action. Use right after exeris-platform-task-classifier, or whenever a task spans modules (Studio / LSP / backend) and needs a plan before any code is written.

Confirm the upstream SDK/tooling dependencies this repo needs are resolvable before a build — local `mvn install` of `eu.exeris:exeris-sdk-*` and `eu.exeris.tooling:*` present at matching versions, and GitHub Packages auth set for any `eu.exeris:*` snapshot pulls. Use on a fresh clone, when `mvn` fails with an unresolved `eu.exeris:*` artifact, when bumping an SDK/tooling version, or before the first reactor build in a session.

Triage step for any incoming exeris-platform task. Use FIRST — before routing or implementation — to classify a Studio / LSP / studio-backend request into task type (architecture / backend / LSP / frontend / docs / cross-build), scope, severity, and primary contract risk, and to name the specialist agent that should own it. Invoke whenever the owning module or the main risk is not yet obvious, or when scope may cross modules.