⚠️ Overall assessment: Good primitive set, with a few data-quality risks to tighten

Summary

This PR adds durable router decision/feedback/review-loop primitives: JSONL-backed store, duplicate detection, calibration summary metrics, gateway API handlers for decision/feedback/review lifecycle, and Slack-driven implicit/reaction ingestion to feed the loop.

What looks good

• Nice end-to-end path from runtime events → store → gateway query/update surfaces.
• Review queue model (open/resolved/dismissed + update log) is practical and auditable.
• Added tests cover core linking, summary metrics, and gateway handler behavior.

Concerns

1. Implicit feedback parser is fairly permissive and may create false positives (src/routing/feedback-loop.ts, src/auto-reply/reply/dispatch-from-config.ts)

   • Regex path \bt([1-4])\b will classify any generic T1/T2/T3/T4 mention as routing feedback.
   • Since this runs in live inbound Slack message flow, noisy capture can inflate mismatch/review metrics.

2. JSONL read path is brittle to single-line corruption (src/routing/feedback-loop.ts)

   • readJsonl() blindly JSON.parses every line; one malformed line can break all reads and disable summary/review APIs.
   • Consider resilient parsing (skip+log bad lines) or atomic write/rotate strategy.

3. Duplicate feedback still creates review items

   • Duplicates are identified (duplicateOfFeedbackId) but still participate in review queue creation and can bias open-review counts.
   • If intentional, worth documenting; otherwise gate review creation for duplicates.

Suggestions

• Tighten implicit parser with stronger intent cues (e.g., require explicit correction phrases when tier is inferred).
• Harden JSONL ingestion against partial/corrupt lines.
• Add tests for duplicate-handling policy in review queue generation.
• Consider normalizing reaction values in one place before shouldReview() checks.

Overall this is a strong first implementation; with those safeguards, it’ll be much more reliable in production telemetry.