You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A maintainer review-stack × Autonomous Miner System (AMS) integration audit (2026-07-09) found that the Wave-3 maintainer analytics dashboard (29 planned cards, 19 MCP tools) has zero miner-vs-human split anywhere in its scope, and the underlying gate-eval engine is structurally incapable of one today.
src/review/parity.ts (computeGateEval) selects only project/target_id/decision from review_audit — no actor/login column.
migrations/0049_review_audit_parity.sql states outright: "Privacy: project + target_id + head_sha + decision + reasonCode + timestamp ONLY. No actor logins" — confirming review_audit, and therefore every stats.ts/GateEvalReport aggregate keyed off it, has zero actor-origin signal, not even a boolean flag.
The one login-keyed substrate that does exist, contributor_gate_history (migrations/0126, src/review/contributor-calibration.ts), is explicitly scoped only to feed a future internal per-actor confidence adjustment (maintainer: personalized gate-prediction tuning per contributor/miner history #2349) — its own design note bars it from ever appearing on a public dashboard or any contributor-facing output, and it isn't wired to the Wave-3 dashboard/MCP surface regardless.
Why this matters for the Autonomous Miner System
Gittensory's own miner fleet (AMS) will be a fast-growing PR source for repos that adopt it. If none of the Wave-3 cards — gate-precision, reversal-rate, findings-by-category, acceptance-rate, gate-outcome breakdown, top-contributors-by-quality-band — can be sliced by contributor origin, a maintainer running a mixed human+miner repo cannot tell whether the gate is systematically mis-calibrated for one cohort, and neither #2348's value-weighted calibration nor #2350's anti-farming detector can be validated per-cohort from the maintainer's own dashboard. Note this is distinct from #2352 (which wires a source-scoped computeGateEval pass into the auto-tune circuit-breaker specifically) — that's an automated enforcement action, not a maintainer-visible dashboard view of the same split.
Deliverables
Add a privacy-safe, aggregate-only "miner-originated" dimension to the tables/aggregates the Wave-3 dashboard cards read from (without reintroducing actor logins into review_audit itself — e.g. a boolean/cohort tag rather than identity)
Tests: cohort split reflects real data without leaking actor identity; existing blended aggregates unaffected when the split isn't requested
Docs: note the new dimension in the dashboard/analytics documentation
Surfaced by a maintainer review-stack × AMS integration audit (2026-07-09). Related: #2013 (Wave-3 Dashboard UI & MCP tracker, which this extends), #1967 (maintainer analytics dashboard umbrella), #2352 (miner-source-scoped auto-tune circuit-breaker — an automated consumer of a similar split, not a dashboard view), #4265 (the self-improve design note that already draws the audience/data-source distinction this issue's dashboard view needs to respect).
Context
A maintainer review-stack × Autonomous Miner System (AMS) integration audit (2026-07-09) found that the Wave-3 maintainer analytics dashboard (29 planned cards, 19 MCP tools) has zero miner-vs-human split anywhere in its scope, and the underlying gate-eval engine is structurally incapable of one today.
Evidence
src/review/parity.ts(computeGateEval) selects onlyproject/target_id/decisionfromreview_audit— no actor/login column.migrations/0049_review_audit_parity.sqlstates outright: "Privacy: project + target_id + head_sha + decision + reasonCode + timestamp ONLY. No actor logins" — confirmingreview_audit, and therefore everystats.ts/GateEvalReportaggregate keyed off it, has zero actor-origin signal, not even a boolean flag.contributor_gate_history(migrations/0126,src/review/contributor-calibration.ts), is explicitly scoped only to feed a future internal per-actor confidence adjustment (maintainer: personalized gate-prediction tuning per contributor/miner history #2349) — its own design note bars it from ever appearing on a public dashboard or any contributor-facing output, and it isn't wired to the Wave-3 dashboard/MCP surface regardless.Why this matters for the Autonomous Miner System
Gittensory's own miner fleet (AMS) will be a fast-growing PR source for repos that adopt it. If none of the Wave-3 cards — gate-precision, reversal-rate, findings-by-category, acceptance-rate, gate-outcome breakdown, top-contributors-by-quality-band — can be sliced by contributor origin, a maintainer running a mixed human+miner repo cannot tell whether the gate is systematically mis-calibrated for one cohort, and neither #2348's value-weighted calibration nor #2350's anti-farming detector can be validated per-cohort from the maintainer's own dashboard. Note this is distinct from #2352 (which wires a
source-scopedcomputeGateEvalpass into the auto-tune circuit-breaker specifically) — that's an automated enforcement action, not a maintainer-visible dashboard view of the same split.Deliverables
review_audititself — e.g. a boolean/cohort tag rather than identity)Surfaced by a maintainer review-stack × AMS integration audit (2026-07-09). Related: #2013 (Wave-3 Dashboard UI & MCP tracker, which this extends), #1967 (maintainer analytics dashboard umbrella), #2352 (miner-source-scoped auto-tune circuit-breaker — an automated consumer of a similar split, not a dashboard view), #4265 (the self-improve design note that already draws the audience/data-source distinction this issue's dashboard view needs to respect).