semantius-deploy-test-maker Skill

This skill takes a *-semantic-model.md file and writes a single self-contained TypeScript file that, when executed with bun, asserts the live Semantius instance contains every entity, field, enum value, permission, role, role-permission link, permission-hierarchy edge, and webhook receiver the model declares, with the exact properties the model specifies.

Why this exists. The deployer is additive: it creates what's missing and updates what differs. Its in-process Stage 5 report (see the deployer skill) confirms the writes it issued, but it does not re-prove the end state from a cold read after the session ends. Manual re-runs of the deployer are still the only mechanism that retries reconciliation. Live state can drift between deploys (an admin edits a field's title in the UI, an entity gets renamed, a role_permission is deleted, a permission_hierarchy edge is dropped). Without a standalone post-deploy check, that drift is invisible until users hit it in production. The user's words: "if any difference between model and semantius platform remain undetected we will all lose our business and maybe existence." Take that seriously. Over-check rather than under-check.

Division of responsibility.

• This skill owns the workflow: parse the model, plan the checks, emit one self-contained TypeScript file. The skill itself does not call Semantius and does not run the test.
• The generated script owns execution: shells out to the semantius CLI, reads live state, compares against the model embedded inline as a JSON constant, prints a structured report, exits non-zero on any mismatch.
• The use-semantius skill owns CLI conventions; this skill borrows its read_* patterns and --single semantics, but applies them inside the generated script rather than at chat time.

Writing conventions (apply to chat output and the generated script)

These match the rest of the semantic-model skill family. Apply them to both the chat narration in this skill and every string the generated TypeScript file prints.

1. US English spellings, always. Examples (left = correct US, right in backticks = banned British form): optimize (not optimise), behavior (not behaviour), modeling (not modelling), labeled (not labelled), normalize (not normalise), analyze (not analyse).

2. No em-dashes (—, U+2014). Use parentheses, commas, periods, or semicolons. Scan output for — before writing any file.