/safina:test

Conformance and correctness check — run before merging. Verifies that your code follows Ilmiya’s engineering standards and does what it says it does.

When to run it

Before merging any branch
After a significant implementation phase
Before handing off to QA

Prerequisites

Unit tests must exist. Before running any standards checks, /safina:test scans for test files covering the code in scope. If new functions, classes, or API handlers were added and no tests exist:

Error: No tests found for [changed files]. Write unit tests before running /safina:test.

You’ll be asked if existing tests cover the code, or if tests will be added. If neither, write tests first. The command won’t silently skip this check.

What it checks

Standards — all embedded in the command

All engineering standards are embedded directly in /safina:test — the command is self-contained and does not require any external files. Standards are applied based on what’s in the diff:

If the diff touches…	Standards checked
New or modified API endpoints	API design, resource naming, standard methods, custom methods, standard fields
Error handling / responses	Error design
Field or variable naming	Naming conventions
Logging, metrics, tracing	Observability, golden metrics
LLM prompts, agents, tools	AI engineering (prompting, agents, harnesses)
API version changes	Versioning, backward compatibility
Proto files	Proto file structure
Performance-sensitive paths	Scaling and performance
Documentation / comments	Documentation

Use /safina:man [topic] to read any standard inline. For example: /safina:man api-design or /safina:man error-design.

Correctness checks

Implementation vs intent — does the function do what its name implies?
Branch exhaustiveness — all conditionals handled, no silent fall-through
Null / undefined safety — guards before dereferencing
Return type contracts — return types match what callers expect

Test coverage checks

Happy path and at least one failure path covered?
Assertions are real (not just “did it run”)?
Tests are isolated (no shared state between cases)?
Mocked dependencies realistic enough to catch integration failures?

QA readiness

Feature self-contained enough to hand off?
Obvious edge cases tested?

Commit convention

Every commit checked against the Ilmiya commit standard:

type(scope): description

Linear: TEAM-NNN   ← Tier 1
Refs: #NNN          ← Tier 2

Valid types: feat · fix · chore · docs · refactor · test · perf · ci Valid scopes: api · platform · myilmiya · devops · infra · safina

The report

## /safina:test — YYYY-MM-DD

Scope: [what was reviewed]
Standards checked: [categories that applied]

### Errors  (N)
file:line — What's wrong. Which rule.
Fix: what to do

### Patches  (N)
[Same format]

### Notices  (N)
[Same format]

### Commit convention  (N non-conforming)
`sha` `message` — what's wrong

### Summary
Overall conformance signal, biggest gap, QA readiness verdict.

Severity guide

Tier	Meaning	Action
Error	Hard standard broken	Fix before moving to `/safina:hunt`
Patch	Quality gap	Fix where possible; don’t silently ship
Notice	Informational	Track; not blocking

Errors can be logged to your ticket

If there are Errors, the command offers to post them as a comment on your active Linear or GitHub issue so they’re tracked.

Prerequisite for

/safina:hunt — run test first, then hunt
/safina:update — unresolved test Errors should be fixed before posting a QA-ready update