@sriinnu/runic 1.2.0 → 2.11.1

package/docs/refactor/macros.md

@@ -1,35 +0,0 @@
----
-summary: "Provider macro refactor ideas and follow-ups."
-read_when:
-  - Reviewing provider macro ergonomics
-  - Planning provider/descriptor refactors
----
-
-# Macro refactor ideas
-
-1. Macro ergonomics + errors
-- Emit compile-time errors when a macro is attached to the wrong target or missing `descriptor`/`init`.
-- Add a member macro to generate `static let descriptor` from `makeDescriptor()` to remove boilerplate.
-
-2. Descriptor/data shape
-- Split ProviderDescriptor into Descriptor + FetchPlan + Branding + CLI files for cleaner deps.
-- Move source label into fetch results (strategy-specific).
-
-3. Fetching pipeline
-- Return all attempted strategies + errors for debug UI and CLI `--verbose`.
-
-4. Registry order & stability
-- Use ProviderDescriptorRegistry registration order for `all`; no sorting by rawValue.
-- Use metadata flags (e.g. `isPrimaryProvider`) instead of hard-coded Codex/Claude.
-
-5. Account/identity
-- Replace Codex UI special casing with a descriptor flag (e.g. `usesAccountFallback`).
-- Enforce provider-keyed identity in snapshots to avoid cross-provider display.
-
-6. Settings + tokens
-- Move Zai/Copilot token lookup into strategy-local resolvers (Keychain/env).
-- Add optional per-provider settings fields in ProviderSettingsSnapshot.
-
-7. Docs + tests
-- Add a minimal provider example in docs/provider.md.
-- Add registry completeness + deterministic-order test.

package/docs/refresh-loop.md

@@ -1,22 +0,0 @@
----
-summary: "Refresh cadence, background updates, and error handling."
-read_when:
-  - Changing refresh cadence, background tasks, or refresh triggers
-  - Investigating refresh timing or stale data behavior
----
-
-# Refresh loop
-
-## Cadence
-- `RefreshFrequency`: Manual, 1m, 2m, 5m (default), 15m.
-- Stored in `UserDefaults` via `SettingsStore`.
-
-## Behavior
-- Background refresh runs off-main and updates `UsageStore` (usage + credits + optional web scrape).
-- Manual “Refresh now” always available in the menu.
-- Stale/error states dim the icon and surface status in-menu.
-
-## Optional future
-- Auto-seed a log if none exists via `codex exec --skip-git-repo-check --json "ping"` (currently not executed).
-
-See also: `docs/status.md`, `docs/ui.md`.

package/docs/releasing-homebrew.md

@@ -1,35 +0,0 @@
----
-summary: "Homebrew Cask release steps for Runic (Sparkle-disabled builds)."
-read_when:
-  - Publishing a Runic release via Homebrew
-  - Updating the Homebrew tap cask definition
----
-
-# Runic Homebrew Release Playbook
-
-Homebrew is for the UI app via Cask. When installed via Homebrew, Runic disables Sparkle and shows a "update via brew" hint in About.
-
-## Prereqs
-- Homebrew installed.
-- Access to the tap repo: `../homebrew-tap`.
-
-## 1) Release Runic normally
-Follow `docs/RELEASING.md` to publish `Runic-<version>.zip` to GitHub Releases.
-
-## 2) Update the Homebrew tap cask
-In `../homebrew-tap`, add/update the cask at `Casks/runic.rb`:
-- `url` points at the GitHub release asset: `.../releases/download/v<version>/Runic-<version>.zip`
-- Update `sha256` to match that zip.
-- Keep `depends_on arch: :arm64` and `depends_on macos: ">= :sonoma"` (Runic is macOS 14+).
-
-## 3) Verify install
-```sh
-brew uninstall --cask runic || true
-brew untap steipete/tap || true
-brew tap steipete/tap
-brew install --cask steipete/tap/runic
-open -a Runic
-```
-
-## 4) Push tap changes
-Commit + push in the tap repo.

package/docs/releasing.md

@@ -1,121 +0,0 @@
----
-summary: "Runic release checklist: package, sign, notarize, appcast, and asset validation."
-read_when:
-  - Starting a Runic release
-  - Updating signing/notarization or appcast steps
-  - Validating release assets or Sparkle feed
----
-
-# Release process (Runic)
-
-SwiftPM-only; package/sign/notarize manually (no Xcode project). Sparkle feed is served from GitHub Releases. Checklist below merges Trimmy’s release flow with Runic specifics.
-
-**Reference first:** follow this Runic-specific guide as the source of truth for release steps.
-
-## Expectations
-- When someone says “release Runic”, do the entire end-to-end flow: bump versions/CHANGELOG, build, sign and notarize, upload the zip to the GitHub release, generate/update the appcast with the new signature, publish the tag/release, and verify the enclosure URL responds with 200/OK and installs via Sparkle (no 404s or stale feeds).
-
-### Release automation notes (Scripts/release.sh)
-- Always forces a fresh build/notarization (no cached artifacts) before publishing.
-- Fails fast if: git tree is dirty, the top changelog section is still “Unreleased” or mismatched, the target version already exists in the appcast, or the build number is not greater than the latest appcast entry.
-- Sparkle key probe runs up front; appcast entry + signature verified automatically after generation.
-- Release notes are extracted directly from the current changelog section and passed to the GitHub release (no manual notes flag needed).
-- Sparkle appcast notes are generated as HTML from the same changelog section and embedded into the appcast entry.
-- Uses in-repo helpers (`Scripts/release-lib.sh`) so release checks no longer depend on external/private script paths.
-- Requires tools/env on PATH: `swiftformat`, `swiftlint`, `swift`, `sign_update`, `generate_appcast`, `gh`, `python3`, `zip`, `curl`, plus `APP_STORE_CONNECT_*` and `SPARKLE_PRIVATE_KEY_FILE`.
-
-## Prereqs
-- Xcode 26+ installed at `/Applications/Xcode.app` (for ictool/iconutil and SDKs).
-- Developer ID Application cert installed (e.g. `Developer ID Application: YOUR_NAME (TEAMID)`).
-- ASC API creds in env: `APP_STORE_CONNECT_API_KEY_P8`, `APP_STORE_CONNECT_KEY_ID`, `APP_STORE_CONNECT_ISSUER_ID`.
-- Sparkle keys: public key already in Info.plist; private key path set via `SPARKLE_PRIVATE_KEY_FILE` when generating appcast.
-- Ensure shell has release env vars loaded (usually `source ~/.profile`) before running `Scripts/release.sh`.
-
-## Icon (glass .icon → .icns)
-```
-./Scripts/build_icon.sh Icon.icon Runic
-```
-Uses Xcode’s `ictool` + transparent padding + iconset → Icon.icns.
-
-## Build, sign, notarize (universal: arm64 + x86_64)
-```
-./Scripts/sign-and-notarize.sh
-```
-What it does:
-- `swift build -c release --arch arm64` and `swift build -c release --arch x86_64`
-- Packages `Runic.app` with Info.plist and Icon.icns
-- Embeds Sparkle.framework, Updater, Autoupdate, XPCs
-- Codesigns **everything** with runtime + timestamp (deep) and adds rpath
-- Zips to `Runic-<version>.zip`
-- Submits to notarytool, waits, staples, validates
-
-Gotchas fixed:
-- Sparkle needs signing for framework, Autoupdate, Updater, XPCs (Downloader/Installer) or notarization fails.
-- Use `--timestamp` and `--deep` when signing the app to avoid invalid signature errors.
-- Avoid `unzip` — it can add AppleDouble `._*` files that break the sealed signature and trigger “app is damaged”. Use Finder or `ditto -x -k Runic-<ver>.zip /Applications`. If Gatekeeper complains, delete the app bundle, re-extract with `ditto`, then `spctl -a -t exec` to verify.
-- Manual sanity check before uploading: `find Runic.app -name '._*'` should return nothing; then `spctl --assess --type execute --verbose Runic.app` and `codesign --verify --deep --strict --verbose Runic.app` should both pass on the packaged bundle.
-
-## Appcast (Sparkle)
-After notarization:
-```
-SPARKLE_PRIVATE_KEY_FILE=/path/to/ed25519-priv.key \
-./Scripts/make_appcast.sh Runic-0.1.0.zip \
-  https://raw.githubusercontent.com/sriinnu/Runic/main/appcast.xml
-Generates HTML release notes from `CHANGELOG.md` (via `Scripts/changelog-to-html.sh`) and embeds them into the appcast entry.
-```
-Uploads not handled automatically—commit/publish appcast + zip to the feed location (GitHub Releases/raw URL).
-
-## Tag & release
-```
-git tag v<version>
-./Scripts/make_appcast.sh ...
-# upload zip + appcast to Releases
-# then create GitHub release (gh release create v<version> ...)
-```
-
-## Homebrew (Cask)
-Runic ships a Homebrew **Cask** in `../homebrew-tap`. When installed via Homebrew, Runic disables Sparkle and the app
-must be updated via `brew`.
-
-After publishing the GitHub release, update the tap cask (see `docs/releasing-homebrew.md`).
-
-## Checklist (quick)
-- [ ] Read this file end-to-end before starting.
-- [ ] Update versions (scripts/Info.plist, CHANGELOG, About text) — changelog top section must be finalized; release script pulls notes from it automatically.
-- [ ] `swiftformat`, `swiftlint`, `swift test` (zero warnings/errors)
-- [ ] `./Scripts/build_icon.sh` if icon changed
-- [ ] `./Scripts/sign-and-notarize.sh`
-- [ ] Generate Sparkle appcast with private key
-  - Sparkle ed25519 private key path: `/Users/sriinnu/Library/CloudStorage/Dropbox/Backup/Sparkle/sparkle-private-key-KEEP-SECURE.txt` (primary) and `/Users/sriinnu/Library/CloudStorage/Dropbox/Backup/Sparkle-VibeTunnel/sparkle-private-key-KEEP-SECURE.txt` (older backup)
-  - Upload the dSYM archive alongside the app zip on the GitHub release; the release script now automates this and will fail if it’s missing.
-  - After publishing the release, run `Scripts/check-release-assets.sh <tag>` to confirm both the app zip and dSYM zip are present on GitHub.
-  - Generate the appcast + HTML release notes: `./Scripts/make_appcast.sh Runic-<ver>.zip https://raw.githubusercontent.com/sriinnu/Runic/main/appcast.xml`
-  - Verify the enclosure signature + size: `SPARKLE_PRIVATE_KEY_FILE=... ./Scripts/verify_appcast.sh <ver>`
-- [ ] Upload zip + appcast to feed; publish tag + GitHub release so Sparkle URL is live (avoid 404)
-- [ ] Homebrew tap: update `../homebrew-tap/Casks/runic.rb` (url + sha256), then verify:
-  - `brew uninstall --cask runic || true`
-  - `brew untap sriinnu/tap || true; brew tap sriinnu/tap`
-  - `brew install --cask sriinnu/tap/runic && open -a Runic`
-- [ ] Version continuity: confirm the new version is the immediate next patch/minor (no gaps) and CHANGELOG has no skipped numbers (e.g., after 0.2.0 use 0.2.1, not 0.2.2)
-- [ ] Changelog sanity: single top-level title, no duplicate version sections, versions strictly descending with no repeats
-- [ ] Release pages: title format `Runic <version>`, notes as Markdown list (no stray blank lines)
-- [ ] Changelog/release notes are user-facing: avoid internal-only bullets (build numbers, script bumps) and keep entries concise
-- [ ] Download uploaded `Runic-<ver>.zip`, unzip via `ditto`, run, and verify signature (`spctl -a -t exec -vv Runic.app` + `stapler validate`)
-- [ ] Confirm `appcast.xml` points to the new zip/version and renders the HTML release notes (not escaped tags)
-- [ ] Verify on GitHub Releases: assets present (zip, appcast), release notes match changelog, version/tag correct
-- [ ] Open the appcast URL in browser to confirm the new entry is visible and enclosure URL is reachable
-- [ ] Manually visit the enclosure URL (curl -I) to ensure 200/OK (no 404) after publishing assets/release
-- [ ] Ensure `sparkle:edSignature` is present for the enclosure in appcast (generated by `generate_appcast` with the ed25519 key)
-- [ ] When creating the GitHub release, paste the CHANGELOG entry as Markdown list (one `-` per line, blank line between sections); visually confirm bullets render correctly after publishing
-- [ ] Keep a previous signed build in `/Applications/Runic.app` to test Sparkle delta/full update to the new release
-- [ ] Manual Gatekeeper sanity: after packaging, `find Runic.app -name '._*'` is empty, `spctl --assess --type execute --verbose Runic.app` and `codesign --verify --deep --strict --verbose Runic.app` succeed
-- [ ] For Sparkle verification: if replacing `/Applications/Runic.app`, quit first, replace, relaunch, and test update
-- **Definition of “done” for a release:** all of the above are complete, the appcast/enclosure link resolves, Homebrew cask
-  installs, and a previous public build can update to the new one via Sparkle. Anything short of that is not a finished release.
-
-## Troubleshooting
-- **White plate icon**: regenerate icns via `build_icon.sh` (ictool) to ensure transparent padding.
-- **Notarization invalid**: verify deep+timestamp signing, especially Sparkle’s Autoupdate/Updater and XPCs; rerun package + sign-and-notarize.
-- **App won’t launch**: ensure Sparkle.framework is embedded under `Contents/Frameworks` and rpath added; codesign deep.
-- **App “damaged” dialog after unzip**: re-extract with `ditto -x -k`, removing any `._*` files, then re-verify with `spctl`.
-- **Update download fails (404)**: ensure the release asset referenced in appcast exists and is published in the corresponding GitHub release; verify with `curl -I <enclosure-url>`.

package/docs/research/concrete_todo_2026-02-22.md

@@ -1,47 +0,0 @@
-# Concrete TODO (Execution List)
-
-Branch: `feat/research-uiux-core-next`
-Last updated: 2026-02-22
-
-## Sprint Goal
-
-Ship operator-grade insights in small, verifiable slices without destabilizing current menu behavior.
-
-## P0 (Now)
-
-- [x] Create research-backed roadmap document  
-  File: `docs/research/feature_uiux_roadmap_2026-02-22.md`
-- [x] Add probabilistic month-end forecast confidence bands (`p50/p80/p95`) to core forecast model
-- [x] Render confidence bands in menu Insights line when available
-- [x] Add/extend tests for confidence-band generation and menu formatting
-
-## P1 (Next)
-
-- [x] Anomaly explainability v2
-  - [x] Add explanation object for why severity was chosen
-  - [x] Surface primary and secondary contributing factors in menu copy
-- [x] Policy engine foundation (warn / soft-limit / hard-stop)
-  - [x] Core model in `RunicCore`
-  - [x] Deterministic decision tests
-
-## P2 (After P1)
-
-- [x] OTel GenAI ingestion adapter (feature-flagged)
-- [x] Team showback/chargeback summary exports
-- [x] Cross-platform parity matrix and release gate checklist
-
-## Immediate Work Plan (This Branch)
-
-1. Extend `UsageLedgerSpendForecast` with optional confidence outputs.
-2. Compute quantiles from observed daily cost distribution in `UsageLedgerAggregator`.
-3. Preserve these fields in `UsageStore` projection-resolution path.
-4. Update menu forecast rendering to show `p50/p80/p95` when available.
-5. Validate with targeted tests and full rebuild script.
-
-## Definition Of Done (Current Slice)
-
-- Forecast model compiles with backward-compatible optional fields.
-- Existing forecast tests pass.
-- New quantile test passes.
-- Menu model test confirms confidence string appears.
-- `./Scripts/compile_and_run.sh` completes successfully.

package/docs/research/core-feature-research.md

@@ -1,248 +0,0 @@
-# Core Feature Research Log
-
-Date: 2026-02-21
-Branch: feat/core
-
-## Goal
-
-Collect concrete, source-backed feature ideas for Runic core roadmap from:
-- GitHub projects (production patterns)
-- arXiv papers (state-of-the-art approaches)
-
-This file is updated incrementally during research to avoid context loss.
-
-## Status
-
-- [x] Research file created
-- [x] Gather current GitHub evidence
-- [x] Gather current arXiv evidence
-- [x] Synthesize feature candidates with implementation notes
-- [x] Prioritize roadmap (Now / Next / Later)
-
-## External Evidence Snapshot
-
-### arXiv evidence (routing, caching, cost/quality)
-
-1. FrugalGPT (2023)
-- Link: https://arxiv.org/abs/2305.05176
-- Signal: Cascaded LLM usage can cut cost heavily while maintaining quality (paper reports very large cost savings in their setup).
-- Relevance to Runic: Runic can add cost-quality simulation and routing recommendations over existing provider usage logs.
-
-2. RouteLLM (2024)
-- Link: https://arxiv.org/abs/2406.18665
-- Signal: Learned routers can route between strong/weak models with significant cost reduction while preserving much of strong-model quality.
-- Relevance to Runic: Add "Routing Advisor" that proposes per-project provider/model policies from real usage history.
-
-3. LLMRouterBench (2026)
-- Link: https://arxiv.org/abs/2601.07206
-- Signal: Large benchmark shows routing is useful, but many methods are brittle and simple baselines are often hard to beat.
-- Relevance to Runic: Favor robust baseline policies first (fallback + threshold + guardrails) before heavier ML routing.
-
-4. vCache (2025)
-- Link: https://arxiv.org/abs/2502.03771
-- Signal: Semantic caching with error-bound control can reduce redundant LLM calls.
-- Relevance to Runic: Add cacheability analytics and "likely cache hit" opportunity scoring per project/workflow.
-
-5. Generative Caching (2025)
-- Link: https://arxiv.org/abs/2503.17603
-- Signal: Cache systems that generate compact responses for similar prompts improve cost/latency.
-- Relevance to Runic: Track prompt similarity buckets and estimate avoidable spend from repeated prompt patterns.
-
-### GitHub and docs evidence (production implementation patterns)
-
-1. LiteLLM
-- Repo: https://github.com/BerriAI/litellm
-- Reliability docs: https://docs.litellm.ai/docs/proxy/reliability
-- Signal: Production-grade patterns include retries, fallbacks, cooldowns, and routing controls.
-- Relevance: Runic should expose policy diagnostics and recommend fallback policy quality from observed failures.
-
-2. Helicone AI Gateway
-- Repo: https://github.com/Helicone/ai-gateway
-- Signal: Unified gateway pattern with routing, load balancing, caching, tracing, and limits.
-- Relevance: Runic can add "Gateway Readiness Score" for teams deciding when to adopt a gateway.
-
-3. Langfuse
-- Repo: https://github.com/langfuse/langfuse
-- Signal: Prompt management, tracing, evals, datasets, and collaborative AI ops workflows.
-- Relevance: Runic should support prompt/version correlation and eval score overlays in usage charts.
-
-4. Promptfoo
-- Repo: https://github.com/promptfoo/promptfoo
-- Signal: Eval + red-team workflows integrated into CI.
-- Relevance: Runic can ingest eval outputs and show quality regressions next to spend spikes.
-
-5. OpenAI Evals
-- Repo: https://github.com/openai/evals
-- Docs link from repo: https://platform.openai.com/docs/guides/evals
-- Signal: Evals are a core mechanism to measure model/version quality impact.
-- Relevance: Runic can include first-class "Eval Health" alongside budget health.
-
-6. OpenTelemetry GenAI semantic conventions
-- Metrics: https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-metrics/
-- Spans: https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-spans/
-- Signal: Standard fields for provider/model/operation/timing are now defined for GenAI telemetry.
-- Relevance: Runic should export normalized telemetry so dashboards/tools interoperate cleanly.
-
-7. MCP specification (tools/prompts)
-- Tools: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
-- Prompts: https://modelcontextprotocol.io/specification/2025-06-18/server/prompts
-- Signal: Standardized tool invocation and prompt serving surface for agentic systems.
-- Relevance: Runic can add MCP-specific analytics (tool error rate, latency, prompt-template performance).
-
-## Feature Candidates (for Runic core)
-
-### A) Routing Advisor + Cost-Quality Simulator
-
-What:
-- Simulate alternative model/provider routing policies against historical usage ledger data.
-- Show projected delta for cost, latency proxy, and quality proxy.
-
-Why now:
-- Directly aligned to FrugalGPT + RouteLLM evidence.
-- Low dependency because Runic already has usage ledger + provider cost paths.
-
-Implementation sketch:
-- Extend `Sources/RunicCore/UsageLedger/UsageLedgerAggregator.swift` with simulation inputs/outputs.
-- Add policy models in `Sources/RunicCore/Performance/PerformanceModels.swift`.
-- Add menu card in `Sources/Runic/Views/Menu/` (new `RoutingAdvisorMenuView.swift`).
-
-### B) Reliability Policy Score (Fallback/Retry/Cooldown quality)
-
-What:
-- Per provider/project score for policy robustness:
-  - failure-rate trends
-  - fallback coverage
-  - timeout/retry efficiency
-  - observed "hard fail with no fallback" incidents
-
-Why now:
-- Practical baseline recommended by LLMRouterBench-style findings.
-- Matches LiteLLM/Helicone operational patterns.
-
-Implementation sketch:
-- Persist policy signals in `Sources/RunicCore/Performance/PerformanceStorageImpl.swift`.
-- Add scoring service in `Sources/RunicCore/Performance/`.
-- Render in `Sources/Runic/Views/Menu/AlertsMenuView.swift` and a dedicated card.
-
-### C) Eval-Linked Spend Analytics
-
-What:
-- Ingest eval outputs (Promptfoo/OpenAI Evals style) and align with cost/usage windows.
-- Show "quality down + spend up" and "quality stable + cost down" events.
-
-Why now:
-- Moves Runic from pure accounting to decision support.
-
-Implementation sketch:
-- New ingest model (JSON/YAML adapter) in `Sources/RunicCore/`.
-- Cross-join with provider/day/project aggregates in usage ledger pipeline.
-- Add view in `Sources/Runic/Views/Performance/PerformanceDashboardView.swift`.
-
-### D) Semantic Cache Opportunity Analyzer
-
-What:
-- Detect repeated or near-duplicate prompt patterns and estimate avoidable token cost.
-- Flag cache-friendly workflows per project.
-
-Why now:
-- Backed by vCache/generative-caching direction and gateway practices.
-
-Implementation sketch:
-- Add prompt fingerprint stats in usage ledger models.
-- Keep first version lightweight: hash + normalized prompt-template fingerprint, not full semantic embeddings.
-- UI card in menu + performance dashboard.
-
-### E) OpenTelemetry GenAI Export
-
-What:
-- Export Runic telemetry in OTel GenAI-compatible fields.
-- Include provider, request model, response model, operation, and latency buckets.
-
-Why now:
-- Standardization unlocks external dashboards and enterprise integrations.
-
-Implementation sketch:
-- Add mapper in `Sources/RunicCore/Logging/` or `Sources/RunicCore/Performance/`.
-- Optional sink to JSON/OTLP compatible format.
-
-### F) MCP Tool and Prompt Analytics
-
-What:
-- Track MCP tool-call rates, latency, error classes, and prompt-template success trends.
-- Show per-project MCP "tool reliability heatmap."
-
-Why now:
-- Agentic workflows are increasingly MCP-centric.
-
-Implementation sketch:
-- Add MCP event model in `RunicCore`.
-- New menu views under `Sources/Runic/Views/Menu/`.
-
-## Data Product Improvements (directly for your current concern)
-
-Your concern:
-- "Insights do not show actual project names reliably."
-
-Likely core issue:
-- Project identity is fragmented across providers/log formats (`projectID` present but often not normalized).
-
-Concrete fixes:
-1. Add project identity normalization pipeline:
-- Canonical key = provider + normalized project slug + optional workspace path hash.
-- Keep alias table for renamed projects.
-
-2. Improve extraction heuristics:
-- Parse project name from known fields and fallback to path/repo hints.
-- Add confidence score per inferred project name.
-
-3. Preserve provenance:
-- Store source field map that produced each project name, to debug mismatches quickly.
-
-4. UI safety:
-- Show "Unknown project" only when confidence is low, with hover details and quick relabel action.
-
-Suggested file touchpoints:
-- `Sources/RunicCore/UsageLedger/UsageLedgerModels.swift`
-- `Sources/RunicCore/UsageLedger/UsageLedgerAggregator.swift`
-- `Sources/Runic/Core/Stores/UsageStore.swift`
-- `Sources/Runic/Views/Menu/ProjectBreakdownMenuView.swift`
-
-## Prioritized Roadmap
-
-### Now (1-2 weeks)
-
-1. Project identity normalization and project-name confidence
-2. Reliability Policy Score (fallback/retry/cooldown diagnostics)
-3. Routing Advisor v1 (baseline simulation only, no ML training)
-
-Acceptance criteria:
-- Insights show stable project names across refresh cycles.
-- At least one actionable routing recommendation per active project.
-- Policy score visible for each enabled provider.
-
-### Next (2-4 weeks)
-
-1. Eval-Linked Spend Analytics (Promptfoo/OpenAI Evals import)
-2. Semantic Cache Opportunity Analyzer (fingerprint-based)
-3. OTel GenAI export (file or endpoint sink)
-
-Acceptance criteria:
-- Can correlate eval deltas with cost deltas per project and time window.
-- Can quantify estimated avoidable spend from repeated prompt patterns.
-- External tools can ingest standardized Runic telemetry fields.
-
-### Later (4+ weeks)
-
-1. MCP tool/prompt analytics and heatmaps
-2. Advanced routing policies (bandit/learned router plugins)
-3. Team-level governance pack (policy presets, compliance reports)
-
-Acceptance criteria:
-- MCP-heavy teams can see tool reliability and prompt effectiveness trends.
-- Multi-provider routing decisions can be tuned with measurable outcomes.
-
-## Notes on methodology
-
-- Preference was given to primary sources (paper pages, official repos/docs).
-- Claims are interpreted conservatively; recommendations emphasize robust baselines first.
-- Research intent here is product-directional, not a claim of guaranteed gain in every workload.