Skip to main content
A finding is one root cause. The agent proposes it; the CLI decides what it becomes.

​
Severity and verification are independent

This is the single most important thing to understand about a Myrqen report.
Deterministic local or authorized evidence demonstrates the issue. Something was requested, and something came back that proves it.
The root cause and a reachable path are strongly supported, but full proof is unavailable or could not be obtained safely. This is the correct label when the only remaining proof would have required a prohibited action.
Plausible, with insufficient validation. A static candidate nobody exercised stays here, and the report says so rather than implying more.
The report filters on both axes separately, so “high impact but unproven” and “proven but low impact” never collapse into one number.

​
What the CLI owns

Findings arrive from the host agent as untrusted-shaped data, so intake — not the agent — owns every decision that a report’s integrity depends on.
1

Identity

The CLI assigns the id, in the form MYR-001. A submission containing an id is rejected.
2

Redaction

Secret-shaped material is redacted on the way in. A finding that still contains a live-looking credential after redaction is rejected, not stored. The result reports how many redactions were applied.
3

Category normalization

Lowercased, whitespace and hyphens folded to underscores, non-alphanumerics stripped, truncated to 120 characters.
4

Fingerprint and deduplication

The fingerprint is category + normalized location + root-cause identity. Concrete identifiers are collapsed, so /orders/12 and /orders/13 are one location, and hex digests and bare numbers in the summary are normalized away.Submit the same root cause again with new evidence and it is merged as corroboration rather than filed as a duplicate. The result says action: "merged_as_corroboration" with deduplicatedInto naming the original.
5

Severity capping

Two rules, both of which produce a warning rather than a silent change — see below.

​
Severity capping rules

Rule 1 — unvalidated criticals are leads. severity: "critical" with verification: "needs_review" is reduced to high:
Severity critical with verification needs_review was reduced to high. Validate the issue to restore critical.
Rule 2 — commonly over-rated categories need runtime evidence. These three categories are capped at medium unless at least one piece of evidence has kind runtime or identity_differential:
  • missing_security_header
  • verbose_error_message
  • outdated_dependency_no_known_exploit_path
Severity for category ”…” was reduced to medium because no runtime or differential evidence was supplied.

​
Evidence kinds

​
Settling a static candidate

The static pass files candidates before the agent starts. Each one is a claim.
Refuting keeps the finding and labels it a false positive, with the reason attached. A reader can disagree with that. They cannot disagree with something silently deleted.
Never resubmit a candidate in order to confirm it. A resubmission merges only when the summary matches the original word for word, so in practice it produces the same issue twice. Use finding verify.

​
Finding status and the fix history

Once remediation starts, a finding also carries a status: open · fix_suggested · fix_applied · fixed_verified · accepted_risk · false_positive Each step appends to fixHistory with an action (suggested, applied, verified, verification_failed, reverted), whether verification actually passed, the changed files, and an optional note. A finding reaches fixed_verified only when a passing verification was recorded. See Fix and retest.

​
What the static pass looks for

packages/scan ships rules across these categories. They are the starting point, not the ceiling — the agent is expected to find root causes the static pass could not reach.

​
Reporting quality

The Agent Skill holds the agent to these:
  • Explain the root cause, not the category name.
  • Say why you believe the finding, and label the evidence kind.
  • Give the smallest durable fix, prefer the framework’s own safeguard, and name a regression test.
  • Do not inflate severity because a category sounds serious.
  • If you found nothing, say what you covered and what you could not reach.

Finding schema

Every field, every rejection rule, and a worked example.

Reports

How findings are rendered, and what a share projection removes.