Part of epic #8286 (Phase 3 — Depth). One combined evaluation issue, three decisions — each a written adopt/defer verdict on this issue, not code.
1. Feature flags
metagraphed shipped PostHog flags (JSONbored/metagraphed#7816: Workers HTTP+KV evaluation, UI client). loopover has a ratified config-as-code mandate (#6440 pattern: .loopover.yml > DB > defaults; env vars bootstrap-only) that PostHog flags would sit in tension with — a fourth, remote, non-versioned config source for repo-level behavior is exactly what the mandate exists to prevent. The honest evaluation frame: is there a UI-only experimentation niche (rollout of UI features on the loopover-operated deploy, A/B on presentation) where remote flags add something config-as-code structurally can't, without touching review-pipeline behavior? Deliverable: a decision doc with that boundary drawn explicitly — likely verdict is "UI-experiments-only or not at all."
2. PostHog Logs
metagraphed is evaluating for Workers tail logs (JSONbored/metagraphed#7764). loopover's log topology differs: self-host servers write structured JSON to stdout/journald (operator-owned), our Workers have tails, our containers (discovery-index, tenant fleet) have container logs. Evaluate whether PostHog Logs (OTLP ingest) earns a place for the loopover-operated slice specifically, vs the existing observability command-center stack. Deliverable: decision doc.
3. Data Warehouse
metagraphed is spiking warehouse connections (JSONbored/metagraphed#7803). loopover's interesting sources: the calibration ledger (cloud D1 + ORB pg), review outcomes, MCP usage — joining product analytics against calibration ground truth could answer real roadmap questions (which review behaviors correlate with reversals). Deliverable: decision doc incl. cost model and whether the D1/pg schemas are exposable without leaking private repo data.
Boundaries
- Decisions only. Anything adopted becomes its own properly-scoped issue afterward.
Part of epic #8286 (Phase 3 — Depth). One combined evaluation issue, three decisions — each a written adopt/defer verdict on this issue, not code.
1. Feature flags
metagraphed shipped PostHog flags (JSONbored/metagraphed#7816: Workers HTTP+KV evaluation, UI client). loopover has a ratified config-as-code mandate (#6440 pattern:
.loopover.yml> DB > defaults; env vars bootstrap-only) that PostHog flags would sit in tension with — a fourth, remote, non-versioned config source for repo-level behavior is exactly what the mandate exists to prevent. The honest evaluation frame: is there a UI-only experimentation niche (rollout of UI features on the loopover-operated deploy, A/B on presentation) where remote flags add something config-as-code structurally can't, without touching review-pipeline behavior? Deliverable: a decision doc with that boundary drawn explicitly — likely verdict is "UI-experiments-only or not at all."2. PostHog Logs
metagraphed is evaluating for Workers tail logs (JSONbored/metagraphed#7764). loopover's log topology differs: self-host servers write structured JSON to stdout/journald (operator-owned), our Workers have tails, our containers (discovery-index, tenant fleet) have container logs. Evaluate whether PostHog Logs (OTLP ingest) earns a place for the loopover-operated slice specifically, vs the existing observability command-center stack. Deliverable: decision doc.
3. Data Warehouse
metagraphed is spiking warehouse connections (JSONbored/metagraphed#7803). loopover's interesting sources: the calibration ledger (cloud D1 + ORB pg), review outcomes, MCP usage — joining product analytics against calibration ground truth could answer real roadmap questions (which review behaviors correlate with reversals). Deliverable: decision doc incl. cost model and whether the D1/pg schemas are exposable without leaking private repo data.
Boundaries