Radar Suite Axis Classification

Radar Suite — Axis Classification Framework

> Every radar in the suite invokes this skill before emitting findings. This is the verification gate and the coaching engine. Findings that do not pass the gate are rejected.

---

Inheritance Note (this is a framework skill, not an audit skill)

This skill inherits radar-suite-core.md for shared schema definitions (Issue Rating Table format, Handoff YAML schema) but does NOT run core's interactive protocols (Session Setup, Pre-Scan Startup, Known-Intentional Suppression, Pattern Reintroduction Detection). Those protocols apply within the audit skills that invoke this framework, not at this skill's level.

This skill is invoked programmatically by audit skills during finding emission; it never runs standalone. There is no /radar-suite-axis-classification slash command, no setup interview, no phases, no progress banner. A radar reads this skill's spec, follows the Invocation Protocol below to classify and coach its candidate findings, then writes them to its own handoff YAML with the required axis + coaching fields.

If you're reading this skill expecting a runnable command, you want a sibling radar instead (/data-model-radar, /ui-path-radar, /roundtrip-radar, /time-bomb-radar, /ui-enhancer-radar, /capstone-radar).

---

What This Skill Does

Three things, in order:

1. Classify every candidate finding on three axes (with axis_3 splitting into two sub-labels, giving four total schema values — see § The Three Axes below): does it break user-visible behavior, is it correct code that is hard to read, or is it dead or unjustified code?
2. Verify the classification against a checklist of concrete evidence checks before the finding can be emitted.
3. Coach with a mandatory better_approach section that cites a real file:line pattern from the audited codebase (not generic advice).

Any radar can invoke this skill. The skill itself does not scan code directly — it provides the framework, the checklist, and the schema gate that each radar uses before writing its handoff YAML.

---

The Three Axes

axis_1 — Real Bug

Code does the wrong thing from the user's perspective. The behavior needs to change.

Examples:

• CSV import freezes the main thread on large files
• Sheet with unsaved changes discards on dismiss with no confirmation
• Platform-branch parity gap: iOS has a dismiss button, macOS does not
• Silent error swallowing with no user feedback

Default audience: end_user Severity: 4-tier scale (critical, high, medium, low) Grade impact: Yes — counts toward fix-before-shipping grade

axis_2 — Scatter (Correct but Hard to Read)

Code runs correctly but is structured in a way that makes the next developer's job harder. The fix is reorganization, not behavior change. No user-visible change after the fix.

Examples:

• Empty-state handlers for the same view scattered 500 lines apart in one file
• Duplicated #if os(iOS) / #else forks for the same UI concern across multiple files
• State machine implicit in boolean flags rather than an enum
• Managers referenced as singletons without a protocol abstraction when other managers in the codebase already have one

Default audience: code_reader Severity: Hygiene scale (urgent, rolling, backlog) Grade impact: No — lives in the hygiene backlog, does not affect ship grade

axis_3 — Dead Code or Smelly

Either unreachable (dead code) or reachable but not clearly justified (smelly). The fix is delete, document, or interrogate.

Two sub-labels:

• axis3dead_code — Unreachable branch. Verified by reachability trace. Cannot be hit from any production call site.
• axis3smelly — Reachable but poorly justified. Defensive guard with no documented failure mode. Error path that logs but cannot actually fire. Field defined in model but not written or read anywhere.

Examples:

• Empty-state branch in a view that is unreachable because an upstream filter removes the empty case
• guard let on a value that is constructed two lines above and cannot be nil
• Model field that has neither write sites nor read sites in the wired-up app (as opposed to a wiring bug, which is axis_1)

Default audience: future_maintainer Severity: Hygiene scale Grade impact: No — lives in the hygiene backlog

---

Verification Checklist (MANDATORY — before every finding emission)

A radar MUST run these checks before assigning an axis and emitting the finding. Each check that was run is logged in the finding's verification_log field. A finding without a verification_log is rejected by the schema gate.

Check 1: Reachability Trace (required for axis_1 dead-end claims)

Rule: Before emitting "this branch is a user-facing dead end," trace the branch back to a production call site.

How:

1. Identify the file and line of the flagged branch
2. Grep for the enclosing function / view struct name across the codebase
3. Walk up call sites at least 2 levels (who calls this view, who navigates here)
4. If no production call site reaches this branch, reclassify as axis3dead_code and emit with the reclassification logged

Log entry:

- check: reachability_trace
  result: "reached from MyProductsView.swift:915 via galleryContent(items) — reachable"
  # or:
  result: "no production call site found; reclassified to axis_3_dead_code"

Check 2: Whole-File Scan (required for "missing handler" claims)

Rule: Before claiming a state / case / branch is unhandled, scan the ENTIRE file (not just the flagged region) for a handler.

How:

1. Read the full file where the finding was detected (or at minimum, grep the whole file for the case name, enum value, or state flag)
2. If a handler exists elsewhere in the same file, reclassify as axis2scatter (the handler exists but is scattered)
3. The original finding is still valid, but its fix is reorganization, not adding missing logic

Log entry:

- check: whole_file_scan
  result: "scanned 1169 lines; no other handlers for .empty case found — finding stands as axis_1"
  # or:
  result: "scanned 1169 lines; handler at LegacyWishesView.swift:847; reclassified to axis_2_scatter"

Check 3: Branch Enumeration (required for any #if claim)

Rule: Before classifying a #if os(iOS) (or any conditional compilation block) as iOS-only or platform-broken, READ both the #if and the #else branches. Do not drop the #else.

How:

1. When a flagged pattern is inside a #if block, read the full block including all #elseif and #else clauses
2. Verify the claim against every branch, not just the one you noticed first
3. If the #else branch handles the case and the radar missed it, the finding is a false positive

Log entry:

- check: branch_enumeration
  result: "#if os(iOS) block at lines 102-118 has #else at 112-116 that handles the macOS case; finding retracted"
  # or:
  result: "#if os(iOS) block at lines 102-118 has no #else; iOS-only code confirmed"

Check 4: Pattern Citation Lookup (required for every better_approach)

Rule: The better_approach coaching field MUST cite an existing pattern in the SAME codebase being audited. Grep for the pattern shape before writing the recommendation. Generic advice ("consider using a protocol abstraction") without a citation is rejected.

How:

1. When writing a better_approach, identify the pattern shape (protocol abstraction, async bridge, typed navigation enum, etc.)
2. Grep the audited codebase for that shape
3. If a match exists, cite it by file:line in the better_approach body
4. If no match exists, fall back to an anonymized shape reference from coaching-examples-generic.md AND note explicitly "no existing pattern found in this codebase"

Log entry:

- check: pattern_citation_lookup
  result: "found similar pattern at Sources/Protocols/CloudSyncManaging.swift:14 (protocol + @MainActor class)"
  # or:
  result: "no existing protocol abstraction pattern found in codebase; using generic template"

Check 5: Source Root Introspection (lightweight on single-root projects)

Rule: Before claiming a field / type / symbol is unused, enumerate the project's actual source roots. Do not hardcode Sources/ as the only root.

How:

1. Read project.pbxproj (Xcode project) or Package.swift (SPM) to get the actual source root list
2. If only one source root exists, this check collapses to "grep the whole root" and is cheap
3. If multiple source roots exist (e.g., Sources/Views/ AND Sources/Features/ AND Sources/Shared/), grep all of them before emitting an "unused" finding

Log entry:

- check: source_root_introspection
  source_roots: ["Sources/"]
  result: "single source root confirmed; full-root grep ran"

---

Coaching Schema (MANDATORY on every finding)

Every finding MUST populate these fields. A finding missing any mandatory field is rejected by the schema gate.

findings:
  - id: [unique-hash]
    # Axis classification (REQUIRED)
    axis: axis_1_bug | axis_2_scatter | axis_3_dead_code | axis_3_smelly

    # Audience (REQUIRED — defaults by axis but may be overridden per finding)
    # axis_1 default: end_user
    # axis_2 default: code_reader
    # axis_3 default: future_maintainer
    before_after_experience:
      audience: end_user | code_reader | future_maintainer
      before: "Concrete description of the experience today from the named audience's POV"
      after: "Concrete description after the fix, same audience"

    # Coaching fields (ALL REQUIRED, including for axis_2 and axis_3)
    current_approach: |
      How the code is structured today. Specific file:line references.
      Describe the shape, not just the location.
    suggested_fix: |
      The minimum change that addresses the immediate finding.
      For axis_1: the bug fix. For axis_2: the reorganization. For axis_3: delete or document.
    better_approach: |
      How a senior reviewer would write this area of the codebase beyond the minimum fix.
      MUST cite an existing pattern in the user's codebase by file:line.
      Format: "Follow the pattern at [File.swift:NN] which [describes what the pattern does]."
      A better_approach without a pattern_citation_lookup entry in verification_log is REJECTED.
    better_approach_tradeoffs: |
      Honest tradeoffs. When the better approach is overkill. When it is the right call.
      At least one sentence of each: when to apply, when not to apply.

    # Verification log (REQUIRED — at minimum, pattern_citation_lookup)
    verification_log:
      - check: reachability_trace | whole_file_scan | branch_enumeration | pattern_citation_lookup | source_root_introspection
        result: "concrete outcome of the check"

    # Existing fields (unchanged from radar-suite-core.md schema)
    description: [plain language]
    confidence: verified|probable|possible
    urgency: critical|high|medium|low
    status: open|fixed|deferred|accepted
    file: [path]
    line: [number]
    file_last_modified: [ISO-8601]
    group_hint: [category for batch operations]
    pattern_fingerprint: [normalized anti-pattern name]
    grep_pattern: [regex]
    exclusion_pattern: [regex]

Schema Gate Rules

A finding is REJECTED (not emitted, returned to the radar for correction) if any of these apply:

1. axis field is missing or not one of the four valid schema values (axis_1_bug, axis_2_scatter, axis_3_dead_code, axis_3_smelly)
2. before_after_experience is missing or any sub-field is empty
3. current_approach, suggested_fix, or better_approach is missing or empty
4. better_approach does not contain a file:line citation (format: [A-Za-z0-9_/+.-]+\.(swift|py|rb|ts|js|kt|java|m|mm|h|hpp|cpp|cc|c|go|rs|cs|php|scala|sql|yaml|yml|toml|json):\d+ — matches common source-file extensions across the languages the radar-suite audits, primarily Swift but including Python/Ruby/Node/Kotlin/Java for time-bomb-radar's multi-language detection patterns)
5. verification_log is missing or does not contain a pattern_citation_lookup entry
6. better_approach_tradeoffs is missing or does not contain both a "when to apply" and a "when not to apply" sentence

When a finding is rejected: the radar must either (a) fix the finding by running the missing checks and populating the missing fields, or (b) downgrade the finding's confidence to possible and explicitly mark it as "coaching incomplete" in the handoff so it is visible as a low-confidence entry rather than dropped silently.

---

Severity and Grade Mapping

axis_1 uses the existing 4-tier severity scale

• 🔴 CRITICAL — pre-launch blocker OR data loss / crash risk
• 🟡 HIGH — user-visible or stability risk; fix before release
• 🟢 MEDIUM — real issue; acceptable to schedule
• ⚪ LOW — nice-to-have; minimal impact

Grade impact: CRITICAL findings cap grade at C. HIGH findings cap at B+. (Same rules as radar-suite-core.md.)

axis2 and axis3 use the hygiene scale

• urgent_hygiene — will bite within 1-2 development sessions (scattered state in a file about to be refactored)
• rollinghygiene — fix opportunistically when touching the file (most axis2 scatter)
• backlog_hygiene — safe to defer indefinitely (stable dead code with documented reason)

Grade impact: NONE. Hygiene findings do not count toward the A-F grade. They live in a separate capstone section.

Two scales coexist in the same handoff

A radar may emit both axis1 findings (severity: critical) and axis2 findings (severity: rolling_hygiene) in the same handoff YAML. The capstone reader splits them by axis, not by severity value.

---

Audience Tagging

Every finding declares its audience. The audience is who experiences the before/after change.

| Axis | Default Audience | Override When | |---|---|---| | axis1 | end_user | The "bug" is a developer ergonomic issue (e.g., crash on a debug-only code path) — override to code_reader | | axis2 | code_reader | The scatter is so bad it causes observable lag from bundle size or view recomputation — override to end_user | | axis_3 | future_maintainer | The smelly code is a hygiene issue a code reviewer would catch in the next PR — override to code_reader |

Why explicit audience matters: axis2 and axis3 findings have no natural end_user experience. Forcing every finding to phrase before/after for the end user makes axis_2/3 findings hand-wavy. Naming the correct audience keeps the coaching grounded.

Writing the before/after per audience:

• end_user — describe what the app does today vs after (from a user's perspective, not developer's)
• code_reader — describe what the code looks like today vs after (from a developer reading the file for the first time)
• future_maintainer — describe what a developer inheriting this code in 6 months would think / trip over

---

Coaching Examples Loader

Before writing better_approach for any finding, the radar loads coaching examples in this order:

1. Check the target project for .radar-suite/project.yaml
2. Read the coaching_examples: array — e.g., [stuffolio, generic] or [generic]
3. Load each named file in order from skills/radar-suite-axis-classification/coaching-examples-.md
4. First-loaded-file wins. When deciding which pattern shape to cite, prefer the example from the earliest file in the coaching_examples load order that has a matching example. Within a single file, all matching examples are equally valid — the radar may choose any of them. The Stuffolio overlay loaded first means Stuffolio-specific citations take priority when auditing Stuffolio; generic falls back when a pattern has no Stuffolio example.

Example .radar-suite/project.yaml for Stuffolio:

coaching_examples:
  - stuffolio
  - generic

**Example for a new project w

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Terryc21
• Source: Terryc21/radar-suite
• License: Apache-2.0
• Homepage: https://github.com/Terryc21/radar-suite

Install and usage instructions live in the source repository linked above.