I like Grok 4.6 the model, I like it for a number of reasons. I like Grok Build too.
However, I've pointed Grok 4.6 at a fairly complex codebase and asked it to review/audit it for issues and it's come back with a whole laundry list of issues. I've passed that list to Kimi and Claude and they both were like "a couple of good catches but some of those are not issues at all". Grok 4.6 is noticeably weaker that Claude Fable 5, Claude Opus 5, Claude Opus 4.8, Kimi K3, GLM 5.3, … your suggestion to use Grok 4.6 instead of a recent Claude doesn't pass empirical scrutiny.
All four done, full suite green, and the earlier probes still pass.
P1-1 — the refusal is now a full transaction. This was wrong twice, each time more subtly: first it wrote the loser's stale tables and deleted the winner's issues; then it re-read issues freshly but still wrote one file stamped with the loser's generation, so headers split and the next writer overwrote the issue. Both versions shared one anomaly — a single-file write inside a store whose commit is an atomic directory swap. Now a refusal discards the writer's work entirely, re-reads the winning generation, adds one row, and commits it the ordinary way. Verified on the reviewer's exact four-step schedule: headers stay on one generation, and the issue survives the next commit.
P1-2 — every mutator takes the lock only after validating. It was fixed in put_claim alone; issue_key, retract_item!, resurrect_item!, set_item_status! and record_run all still grabbed it first. Five probes confirm each refusal now leaves the lock free.
P1-3 — one parse, shared. Gazetteer.implementation_status is now the single reading, defaulting an absent attribute to missing and rejecting anything outside present | missing. Validation and the store had opposite defaults for the same absence, which is why it wedged bootstrap: validation accepted, the store refused, and the adoption changeset had already committed. version=v999 is also rejected now — only the grammar version was ever checked.
P2 — the oracle's generation read updated, and that is the only line I touched in it: an interface read, not an expectation. It's running now; I'll have a number shortly. The code contradiction fixture is still built on an omitted battery cell, so it may well stop there — that one needs rebuilding around grammar growth, and it changes what the test means, so it stays the reviewer's call.
For the restart, the state is: G2's three cards closed on substance and evidenced by probe; the commit atomic via renameat2(RENAME_EXCHANGE) with a journal fallback; corpus at gazetteer/data/, run 1, 94 items and 1,154 claims. Outstanding: the oracle's fixture, and #206's exhaustive matrices, which you've descoped.
Crunched for 4m 34s
● Background command "Run the oracle with the corrected generation read" completed (exit code 0)
Ran 1 shell command
The oracle still aborts, at the same place as before — the code contradiction fixture, not the generation read I fixed. Certificate is still stamped 21:25 from two runs ago, so there is still no measured post-#207/#208/#206 number, and I won't quote the old one.
Final state for the restart:
Done this session. #207 (payload-aware total policy, 2000-cell matrix, all guards proven load-bearing), #208 (validation total over the declared contract, battery completeness, reconciliation fixes), #206 (atomic multi-file commit via renameat2(RENAME_EXCHANGE), lock moved beside the corpus, generation in the table headers), plus two rounds of review findings including today's four. make test green. Corpus at gazetteer/data/, run 1, 94 items, 1,154 claims, no open issues.
Genuinely unmeasured, and this is the honest gap to carry forward: every claim I've made about G2 rests on my own gates and targeted probes. The independent oracle has not completed a run since before #207 landed. Its blocker is one fixture that builds a corpus by omitting a battery cell — which #208 deliberately made invalid — and rebuilding it around grammar growth changes what the test asserts, so it wants the reviewer rather than me.
Two design consequences that aren't yet in gazetteer.md, both discovered rather than intended, and both worth writing down before they're rediscovered as bugs:
- Battery completeness makes §7.2's drift unreachable through a valid emission — a decider that answers nothing now produces a refused survey instead of a quiet drift issue.
- The same rule makes §5's conflict reachable only through grammar growth, since a human can never own a cell code always answers.
One open judgement I'd put in front of you early: whether to keep the journal fallback at all. It's now the sole consumer of that machinery, runs only on hosts this project doesn't target, and is the less-tested of two protocols precisely when things are abnormal. Deleting it leaves one commit path with one set of invariants.
That's a lot of system specific jargon. I can understand being befuddled by this if you are unfamiliar with system details, especially given that you don't always need to care; future agents need to care.
Little tip if you're vibe(ish) coding: Use some sort of memory system (be it markdown files, wiki, lightweight issue tracker, etc.) and tell it to put full context for feature work in the ticket, enough that a new session can work the ticket, including acceptance criteria. Then have the implementation agent do a /goal to drain the work items until they'll done/closed (only close when acceptance criteria is met) or blocking human interaction, putting all important context from the work into comments on the work item during closing.
It will pile all its dense verbiage into those work items when it closes them, and, in my experience, will only bubble up significant questions and notes to you the user if they are significantly important.
You don't have to think about all that shit you posted. Future coding agents do. So I also make sure it searches for related work items before creating a new one. I use Fable 5 xhigh to plan the work items (costs very little because there aren't many output tokens) and Opus 5 med/high to drain the work item queue.
I had it build a significant system at work last week in my spare time, enough that it would have been 4 or 5 sprints worth of work. Cost me ~$250 in Opus 5 credits (on my company dime, I would have used a subscription or cheaper model and it would have been much less) and ~$40 in Fable 5 credits. You know how much Opus 5 ruminating on system design I had to read? Literally none. I saved my time reading things for reading the code it produced in the places I knew would be need to be modular and extensible, so that I made sure future work wouldn't have a lot of tech debt to pay when it came time to extend it.
There have been 34 Twitter/X link submissions in the past day, ~that's 12,000 submissions a year.
If your reason is that you have to be logged in to use it properly then I'd nearly agree with you. If it's for any other reason, how about no?
reply