Pin kai-engine v0.6.64: kai gate list selects holds in SQL

[jschatz1]

Summary

• kai gate list --json is what kit's gate backstop runs at kai do start, before each dispatch, and at exit. The engine before this pin decoded every snapshot payload in every workspace project to answer it: 3.9s of CPU per call here.
• kai-engine v0.6.64 (kaicontext/kai-engine#87) selects held snapshots by status through a partial expression index: 0.07s, identical hold set. Also carries kai-ci: ship kit in the toolbox image, and push to the registry production reads #88 (WaitDelay on every engine subprocess).

Test plan

• go build ./... && go test ./cmd/kai
• kai gate list --json from the kai workspace: 3.9s → 0.07s, same three holds

🤖 Generated with Claude Code

[greptile-apps]

jschatz1 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: b5dbe903-38e2-4d87-97e3-3ff529319696

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[kaicontext]

Kai review

Kai Summary

Read the whole thing — it does what it says, and nothing jumped out at me. ✅

Review

Scope: kaicontext/kai-cli, the merged pin moving github.com/kaicontext/kai-engine v0.6.56 → v0.6.64 in go.mod plus the matching go.sum hashes. The optimization the PR claims — kai gate list selecting held snapshots via a SQL expression index instead of decoding every snapshot payload — lives in kai-engine, a fetched dependency this checkout does not hold source for. I could not read that module's ListHeld implementation, so I cannot confirm the "3.9s → 0.07s, same holds" claim from here; that is the limit of this review, not a defect.

What the change does: Bumps a single dependency version. No Go source in this repo changed. I confirmed the pin is internally consistent: go.mod declares v0.6.64 as a direct require (no // indirect), go.sum lines 112–113 carry exactly the two matching v0.6.64 hashes (module + go.mod), and no v0.6.56 reference survives anywhere in go.mod or go.sum. There is no replace directive pointing kai-engine elsewhere, so the build resolves the published v0.6.64.

The CLI surface is unchanged and compatible with what the engine returns. runGateList and runGateListSingle in cmd/kai/gate.go call safetygate.ListHeld(p.DB) and then read scalar fields off node.Payload (gateVerdict, gateBlastRadius, integratedFrom, createdAt) plus node.ID. That contract — return held snapshot *graph.Nodes — is what v0.6.64's SQL-index path must continue to satisfy, and nothing in this diff perturbs it. Within kaicontext/kai-cli, safetygate.ListHeld has 8 call sites (gate.go ×3, internal/tui/views/gate.go ×3, argproviders.go, gate_review.go); all are pure consumers of the returned nodes and would benefit identically from the engine speedup, and none would break if the engine returns the same nodes faster. The JSON output shape (gateListEntry struct, gate.go:36) is also untouched.

One limitation, named once: the performance claim and the "same holds" guarantee both rest on kai-engine v0.6.64's behavior, which I cannot read from this repository. If v0.6.64's index-based selection changed which snapshots are considered "held" — e.g. filtering on a status value the old payload-decode path treated differently, or dropping a status the CLI's downstream approve/reject/diff consumers rely on — that would surface as a behavioral regression in kai gate list output, not a compile error here. I have no evidence of such a change, only the inability to rule it out from this checkout. The author, who can see the engine diff, is the one positioned to confirm the held-set is identical.

This is a clean, minimal version pin: two lines in go.mod, two hash lines in go.sum, no source changes, no signature drift, no orphaned old version. Nothing here charges a customer, limits one, publishes on their behalf, deletes, or changes access — it's a performance fix to an internal query path. No decisions to hand back.

This is ready to merge.

Important files changed

File	Change
go.mod	modified · +1 −1
go.sum	modified · +2 −2

What I opened — 4 files, 16 turns, 46s

• cmd/kai/contract_cmd.go
• cmd/kai/gate.go
• go.mod
• go.sum

_{+3 −3 · 2 files · reaches 0 · the full analysis
💬 Reply to any of my comments and I'll answer, or say @kaicontext anywhere on this PR — a question, or "take another look at the retry logic".}