---
name: straion-check-compliance
description: |
  Validates code, specifications, and tasks against project rules using Straion rule matching. Use when checking compliance, validating PRs, reviewing specs against rules, or when user asks "does this meet rules", "check compliance", "validate this/with/against".
---

# Validating Rules

## Process

1. Receive description of what to validate (spec, task, or code)
2. Run `straion find-rules`:

   ```bash
   straion find-rules \
     --title "<spec title>" \
     --body "<full spec content>" \
     --summary "<brief summary>" \
     --files "<key files involved>" \
     --tags "<applicable scope tags>" \
     --keywords "<relevant technical keywords>"
   ```

   - `--title` (required) with a short title of the spec, task, or change
   - `--body` (required) with the detailed description of the spec, task, or change
   - `--summary` with higher-level context (the overall plan or feature)
   - `--files` with the key files involved (languages are derived from extensions)
   - `--tags` with applicable scope tags (e.g. `api,domain,testing,security`)
   - `--keywords` with relevant technical keywords (e.g. `jwt,auth,caching`)

   Run `straion find-rules --help` for the full flag list and scope-tag whitelist.

3. Analyze compliance against each returned rule
4. Record a decision for each with the `record_verdict` tool
5. Report structured findings

## Validation Levels

| Level | What                 | Check Against                             |
| ----- | -------------------- | ----------------------------------------- |
| Spec  | PRDs, ADRs, RFCs     | Architecture, security, design principles |
| Task  | Implementation tasks | Technical rules, API contracts, testing   |
| Code  | Actual changes       | Coding standards, security, performance   |

## Compliance Analysis

For each rule returned by the CLI:

1. Read and understand what it mandates/prohibits
2. Compare against the input
3. Identify gaps or violations
4. Assess severity (critical, important, minor)

## Recording a decision

`straion find-rules` prints each rule prefixed with a short `[shortcode]`, e.g.
`- [3kQ9fX2a] Users must be able to log in with email and password`. Copy the
shortcode verbatim from the CLI output — it is what links a decision back to its
rule, so never invent or paraphrase one.

Record a decision for **every** rule it returned, using the `record_verdict`
tool:

```
record_verdict(
  verdicts: [
    {
      shortcode:  "3kQ9fX2a",
      assessment: "violation",
      decision:   "fix",
      reason:     "will add the missing input validation in this change"
    },
    { shortcode: "7mPq2LxR", assessment: "compliant" }
  ]
)
```

Writing your findings in a message records nothing. Only this tool does, and you
cannot end a turn while any rule is still unresolved.

Record every rule you have judged in one call.

**`assessment`** is your judgement of whether the rule was met:

| Value       | Meaning                                       |
| ----------- | --------------------------------------------- |
| `compliant` | The rule is met.                              |
| `partial`   | Partly met. Treated exactly like `violation`. |
| `violation` | The rule is broken.                           |

**`decision`** is what happens about a violation. Required for `partial` and
`violation`. Leave it unset for `compliant` — a rule that is met has
nothing to decide, and the pair is refused:

| Value            | Meaning                                 |
| ---------------- | --------------------------------------- |
| `fix`            | You will correct it in this change.     |
| `accept`         | It ships broken, on purpose.            |
| `not-applicable` | The rule does not apply to this change. |

**Propose `fix` unless the person has already said otherwise.** `fix` and
`compliant` are recorded silently. `accept` and `not-applicable` interrupt the
person with an approval prompt, so never reach for them on your own initiative —
they are for decisions a person has already made.

A rejected prompt means you proposed something other than what was meant, and
nothing was recorded. Do not call the tool again with the same arguments — ask
what they wanted instead, then record that.

## Output Format

Report your findings in conversation as well — the tool is the audit
trail, this is what the person reads:

```
## Rules Validation Report

### Summary
[X rules checked, Y compliant, Z issues]

### Compliant
- [3kQ9fX2a] [Rule summary] — [What was done correctly]

### Partial Compliance
- [7mB1cV4d] [Rule summary] — [What's missing]
  - **Recommendation**: [Specific fix]

### Violations
- [9pR2dN8e] [Rule summary] — [The violation]
  - **Risk**: [Impact]
  - **Fix**: [Concrete solution]
```

## Severity Guidelines

- **Critical**: Block until fixed
- **Important**: Address before proceeding
- **Minor**: Note for consideration

## Validation Loop

When violations are found:

1. Report specific violations with concrete fixes
2. User applies fixes
3. Re-validate, and record each fixed rule again as `assessment: "compliant"` —
   a decision goes stale when the files it covered change
4. Repeat until critical violations are resolved