root 8d02c7f441 auditor: integrate Kimi second-pass review (off by default, LH_AUDITOR_KIMI=1)
Adds kimi_architect as a fifth check kind in the auditor. Runs
sequentially after static/dynamic/inference/kb_query, consumes their
findings as context, and asks Kimi For Coding "what did everyone
miss?" — targeting load-bearing issues that deepseek N=3 voting can't
see (compile errors, false telemetry, schema bypasses, determinism
leaks). 7/7 grounded on the distillation v1.0.0 audit experiment
2026-04-27.

Off by default. Enable on the lakehouse-auditor service:
  systemctl edit lakehouse-auditor.service
  Environment=LH_AUDITOR_KIMI=1

Tunable env (all optional):
  LH_AUDITOR_KIMI_MODEL       default kimi-for-coding
  LH_AUDITOR_KIMI_MAX_TOKENS  default 12000
  LH_GATEWAY_URL              default http://localhost:3100

Guardrails:
- Failure-isolated. Any Kimi error / 429 / TOS revocation returns a
  single info-level skip-finding so the existing pipeline never blocks
  on a Kimi outage.
- Cost-bounded. Cached verdicts at data/_auditor/kimi_verdicts/<pr>-
  <sha>.json with 24h TTL — re-audits within the window return cached
  findings instead of re-calling upstream. New commits produce new
  SHAs so caching is per-head, not per-day.
- 6min upstream timeout (vs 2min for openrouter inference) — Kimi is
  a reasoning model and the audit prompt is large.
- Grounding verification baked in. Every finding's cited file:line is
  greppped against the actual file before the verdict is persisted.
  Per-finding evidence carries [grounding: verified at FILE:LINE] or
  [grounding: line N > EOF] / [grounding: file not found]. Confab-
  ulation rate goes into data/_kb/kimi_audits.jsonl as grounding_rate
  for "is this still valuable" tracking.

Persisted artifacts:
  data/_auditor/kimi_verdicts/<pr>-<sha>.json   full verdict + raw
                                                Kimi response + grounding
  data/_kb/kimi_audits.jsonl                    one row per call:
                                                latency, tokens, findings,
                                                grounding rate

Verdict-rendering: kimi_architect now appears in the per-check
sections of the human-readable comment posted to PRs (auditor/audit.ts
checkOrder), after kb_query.

Verification:
  bun build auditor/checks/kimi_architect.ts   compiles
  bun build auditor/audit.ts                   compiles
  parser sanity (3-finding fixture)            3/3 lifted correctly

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-27 05:39:51 -05:00
..

Lakehouse Claim Auditor

A Bun sub-agent that watches open PRs on Gitea, reads the ship-claims in commit messages and PR bodies, and hard-blocks merges when the code doesn't back the claim.

Rationale: when "compiles + one curl works" gets called "phase shipped," placeholder code accumulates. This auditor runs every 90s, fetches each open PR, and subjects it to four checks:

  1. Static diff — grep/parse looking for placeholder patterns
  2. Dynamic — runs the never-before-executed hybrid test fixture
  3. Cloud inference — asks gpt-oss:120b via /v1/chat to identify gaps in the diff
  4. KB query — looks up data/_kb/ + observer for prior failure patterns on similar claims

Verdict is assembled, posted to Gitea as:

  • A failing commit status (hard block — branch protection prevents merge)
  • A review comment explaining every finding

Run manually

cd /home/profit/lakehouse
bun run auditor/index.ts

Defaults: polls every 90s, stops on auditor.paused file present.

State

  • data/_auditor/state.json — last-audited head SHA per PR
  • data/_auditor/verdicts/{pr}-{sha}.json — per-run verdict record
  • data/_kb/audit_lessons.jsonl — one row per block/warn finding, path-agnostic signature for dedup. Tailed by kb_query on each audit to surface recurring patterns (2+ distinct PRs with same signature → info, 3-4 → warn, 5+ → block). This is how the auditor learns.
  • data/_kb/scrum_reviews.jsonl — scrum-master per-file reviews. If a file in the current PR has been scrum-reviewed, kb_query surfaces the review as a finding with the accepted model and attempt count.

Where YOU edit

auditor/policy.ts — the verdict assembler. Controls which findings block vs warn vs inform. All other code is mechanical: fetching, running checks, posting to Gitea.

Hard-block mechanism

  1. Commit status is posted as failure with context lakehouse/auditor
  2. If main branch protection requires lakehouse/auditor status to pass, Gitea prevents merge
  3. When code is fixed and re-audit passes, status flips to success, merge unblocks

Enable branch protection (one-time, via Gitea UI or API):

  • POST /repos/profit/lakehouse/branch_protections
  • {"branch_name": "main", "required_status_checks": {"contexts": ["lakehouse/auditor"]}}