feat: 7 cost detectors emit no Signal — ratio bars render empty in finding cards, breaking the core visual output for overprovisioning findings

[prince-pokharna]

Problem statement

The boxed cost-finding cards introduced on 2026-05-03 render an inline
request ████░░░░ limit ratio bar driven by pkg/rules.Signal. However,
todo.md explicitly documents that 7 of the 30 detectors do not yet
populate Signal, causing their cards to render with an empty bar slot —
degrading the primary visual output for some of the most common and
high-savings findings.

Proposed solution

For each affected detector in pkg/rules/, populate Signal during
Detect() using the already-parsed resource values from the Workload
model:

// Example: oversized-cpu-limit detector
func (d *OversizedCPULimitDetector) Detect(w parser.Workload) []Finding {
    // ... existing logic ...
    return []Finding{{
        DetectorID: "oversized-cpu-limit",
        Severity:   SeverityMed,
        Signal: &Signal{
            Observed: w.Resources.Limits.CPU,
            Limit:    recommendedCeiling(w.Resources.Limits.CPU),
            Unit:     "CPU",
        },
    }}
}

Each fix requires a corresponding golden fixture update in
testdata/fixtures/ per CONTRIBUTING.md requirements.

Alternatives considered

Detectors Affected (confirmed in todo.md)

Detector ID	Finding Type	Signal Missing
oversized-cpu-limit	CPU limit far exceeds typical utilization	No ratio bar
oversized-memory-limit	Memory limit grossly overprovisioned	No ratio bar
excessive-replica-count	Replica count disproportionate to load profile	No ratio bar
tiny-cpu-request	CPU request too low — throttling risk	No ratio bar
tiny-memory-request	Memory request below safe operating floor	No ratio bar
cpu-without-memory-request	CPU set, memory missing entirely	No ratio bar
memory-without-cpu-request	Memory set, CPU missing entirely	No ratio bar

Impact

These are not edge-case detectors — overprovisioned CPU/memory limits and
asymmetric resource pairs are among the most frequently triggered findings
on real-world Helm charts.

When these detectors fire, users see a cost card with a blank ratio bar where
quantitative evidence should appear:
┌─ MED · api ──────────────────────────── save ~$18.40/mo ─┐

│ │

│ CPU limit appears overprovisioned │

│ │

│ CPU (no bar) │

│ │

│ confidence: ●●○ medium │

└──────────────────────────────────────────────────────────┘

This directly undercuts the "prove it with numbers" trust contract the
output is designed to establish, and weakens the CLI's CI gate credibility
when the bar — the primary quantitative signal — is absent.

What Signal Should Carry Per Detector

Detector	Signal.Observed	Signal.Limit	Signal.Unit
oversized-cpu-limit	parsed limit value	recommended ceiling	"CPU"
oversized-memory-limit	parsed limit value	recommended ceiling	"Mi"
excessive-replica-count	declared replicas	recommended max	"replicas"
tiny-cpu-request	parsed request value	minimum safe floor	"CPU"
tiny-memory-request	parsed request value	minimum safe floor	"Mi"
cpu-without-memory-request	CPU request present	0 (absent)	"Mi"
memory-without-cpu-request	memory request present	0 (absent)	"CPU"

Scope

New analysis rule

Are you willing to contribute?

• I can implement this if guidance is provided
• I can test this once it's built
• I'm just suggesting the idea

[github-actions]

Welcome to optiqor-cli, and thanks for opening your first issue!

A maintainer will triage this within 48 hours. While you wait:

• Read CONTRIBUTING.md if you'd like to send a fix
• Try it on your own chart: npx @optiqor/cli analyze ./your-helm-chart
• Discussions for questions and design talk

Tip: if you can paste the output of optiqor analyze --debug ./your-chart (or a minimal chart fragment that reproduces) we'll diagnose 90% faster.