Store Signals

Pull what the shipped app is actually telling you and convert it into the next backlog — then verify whether last cycle's bets paid off.

This is the missing arc that turns build → ship into a loop: ship → MEASURE → DIAGNOSE → next PLAN → build → ship → measure again… The ledger (SIGNALS.md) is what makes it a loop and not a monthly report.

Where it fits (read the seams)

• Not analytics-interpretation. That interprets a metric you hand it (is 14% D7 good?). This is the end-to-end operate loop: gather every signal → cluster → diagnose → write a metric-tagged backlog → close last cycle's hypotheses. It uses analytics-interpretation's benchmarks.
• Read-only on ASC. Never responds to reviews, never mutates metadata/pricing. It surfaces, gates on explicit OK, and routes the change to the right command (next-version, bugfix, metadata).
• Feeds planning. Output is a dated backlog appended to ROADMAP.md + rows in SIGNALS.md, consumed by /apple:next-version / /apple:release.