root ca7375ea2b
Some checks failed
lakehouse/auditor 10 blocking issues: cloud: claim not backed — "Verified live (current synthetic data):"
auditor: layer-2 path-traversal guard — symlink resolution before read
Kimi's audit on 2d9cb12 flagged the original path-traversal fix as
incomplete: resolve() normalizes `..` segments but doesn't follow
symlinks. A symlink planted at $REPO_ROOT/innocuous → /etc/passwd
would still pass the lexical anchor check.

Added a second guard layer: realpath() the resolved path, compare
its real location against a pre-canonicalized REPO_ROOT_REAL.
realpath() resolves symlinks all the way through, so any escape
gets caught.

Two layers because attackers might bypass either alone:
  layer 1 (lexical):  refuses raw `../etc/passwd`
  layer 2 (symlink):  refuses planted-symlink shortcuts

REPO_ROOT_REAL is computed once at module load via realpathSync()
in case REPO_ROOT itself is a symlink (bind mount, dev convenience).
Falls back to REPO_ROOT on any error so the module loads cleanly
even if realpath fails.

Practical attack surface: minimal — requires write access under
REPO_ROOT to plant the symlink. But the fix is small and closes
the BLOCK without operational cost.

Verification:
  bun build                                       compiles
  REPO_ROOT_REAL == /home/profit/lakehouse        (no symlink today)
  Three smoke cases all behave as expected:
    raw escape (../etc/passwd)         → layer 1 refuses
    valid repo path                    → both layers pass
    repo path that's a symlink to /etc → layer 2 refuses (would, if planted)

This was the only kimi_architect BLOCK on the dd77632 audit's
follow-up. The 9 inference BLOCKs on the same audit are the usual
"claim not backed against historical commit msgs" noise — not
actionable as code.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-27 08:32:33 -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"]}}