SIGNAL-SCORE-001: Implement explainable signal-strength scoring

[jamalfrnk]

Problem

technical-analysis.ts computes real indicators (EMA/MACD/RSI/ADX/Fisher Transform/Keltner/ATR per prior audit) but there is no unified, explainable 0-100 "signal strength" score model -- indicator outputs aren't currently composed into a single defensible score.

Repository evidence

server/src/technical-analysis.ts -- indicator computation exists; no scoring/composition layer or versioning scheme found.

Risk

P2 -- valuable product/educational feature, not release-blocking, but load-bearing for BACKTEST-001 (which needs a stable, versioned signal to grade) and for the "signal strength vs backtest evidence vs sample adequacy" distinction the mission requires.

Scope

• Deterministic, versioned score model (0-100) from actually-implemented indicators only -- no invented indicators.
• Documented, non-arbitrary weighting rationale for trend agreement, momentum agreement, trend-strength confirmation, volatility suitability, data freshness, indicator availability, conflicting conditions, invalidation conditions.
• Expose total score, direction, component scores, indicators used/missing, freshness status, signal-engine version, score-model version, candle interval, source/generation timestamps, plain-language explanation.
• Label as "Signal strength" everywhere in the UI/API, never probability/confidence/expected-return language.
• Explanatory tooltip/details text per the mission's specified copy.

Non-goals

No claim of statistical calibration (score is agreement-based, not a calibrated probability) unless a future model proves otherwise; no per-user customizable weighting in this issue.

Dependencies

None strictly, but the score model's version needs to be stable before BACKTEST-001 references it.

Proposed implementation

A pure, DB-free scoring function (following the existing pattern of keeping computation testable without DB coupling, as used in analytics/metrics.ts) taking indicator outputs and freshness/availability flags, returning the full score contract as a Zod-validated shape shared client/server (mirroring the analytics.ts discriminated-union pattern from DATA-015).

Acceptance criteria

Score, direction, component breakdown, and versions are computed deterministically for a fixed indicator-input fixture; UI never uses banned probability/confidence language; explanation copy matches the mission's required tooltip text.

Definition of done

Unit tests cover deterministic scoring across representative indicator-agreement/disagreement fixtures; reviewer PASS; docs/product/signal-strength.md written.

Test plan

Fixed-fixture tests: full agreement (near-100), full disagreement (near-0), missing-indicator handling, stale-data handling, invalidation-condition triggering, version-stability across repeated runs with identical input.

Security review

No new external input surface -- purely a computation over already-validated internal data.

Accessibility review

Score display must not rely on color alone (mission-mandated for charts, applies here too).

Observability requirements

Log signal-generation duration and any indicator-computation failures with reason.

Performance considerations

Scoring must not materially slow the existing 30s signal-generation cycle.

Rollback plan

Revert PR; existing raw-indicator signal generation is unaffected as a fallback.

Documentation requirements

docs/product/signal-strength.md.

Completion evidence

(added on merge)

Reviewer verdict

(pending)

[jamalfrnk]

Completion evidence

PR: #60 (open, ready to merge -- commit 60b225b).

Independent review: PASS (after one rework cycle). First pass found a confirmed High-severity regression: signals.signal_score is a nullable column by design (this dev DB alone had 6,728 of 6,731 signal rows with a null score), but the client's Signal.signalScore type was non-nullable and SignalStrength dereferenced it directly -- rendering any un-scored signal crashed with Cannot read properties of null (reading 'totalScore'), which the app's top-level ErrorBoundary caught by blanking the entire Signals page. Reproduced directly by the reviewer via a throwaway render test.

Fixed: Signal.signalScore is now SignalScore | null, SignalStrength renders an explicit "Not available" state for un-scored signals, and a regression test covers both cases. Also addressed two non-blocking Low findings (an inconsistent zero-guard in volatilitySuitability, and two additional test fixtures for missing-momentum and all-indicators-null cases).

Re-review: PASS, verified by reproduction (not just re-reading the diff) -- the reviewer ran the exact null-score case that previously crashed and confirmed it no longer does, confirmed the real-score path has no regression, and confirmed both Low findings are genuinely fixed with correct assertions.

What shipped: a deterministic, versioned 0-100 "Signal strength" score composing the existing EMA/MACD/RSI/ADX/Fisher/Keltner/ATR indicators into six weighted components, conflict detection (exact 0 when trend/momentum disagree), invalidation detection (capped at 15 for secondary warning signs), full test coverage (10 unit tests), a nullable signals.signal_score column (historical signals correctly show as un-scored rather than fabricating evidence), client UI, and docs/product/signal-strength.md.

Verified end-to-end against live Hyperliquid mainnet data during implementation, including a real invalidation-condition case (RSI oversold correctly capping a live SHORT signal at 15/100).