When Scarab Diagnostic Suite started taking shape, I thought I was building diagnostics.
That was the obvious word for it.
AI coding agents were ...
For further actions, you may consider blocking this person and/or reporting abuse
Strong overlap with something I just published on the same axis: dev.to/jugeni/vibe-coding-is-not-a-level-its-an-axis-12gb
You're solving the tooling side — deterministic governance layer that catches drift. I framed it as a missing horizontal axis next to the autonomy ladder ("L1 + High operator discipline > L5 + Low operator discipline"). Different vocabulary, same underlying claim: the model alone can't be the source of truth about the repo.
The line "agent should not have to invent the repo's architecture every time it opens a task" is exactly the failure mode that locked decisions and source-anchored notes are designed to kill. Different angle of attack on the same problem.
Curious how Scarab handles the capture habit — in my setup that's the hardest part, not the schema.
I think this is a useful overlap, but I’d separate the layers a little more sharply.
What you’re describing feels to me like operator-side continuity: decisions, notes, locked choices, provenance, and context that survives across sessions. That can absolutely reduce relitigation and make the model less wobbly over time.
But I don’t think that is the same problem Scarab is aimed at.
Scarab is not really trying to improve the operator’s memory discipline or create a better note store for the model. The target is repo-side technical governance: what the codebase itself can expose as evidence, boundaries, obligations, drift surfaces, source-truth relationships, and verification findings.
So when you ask about the capture habit, my answer is that Scarab tries to move capture away from “the operator remembered to record the decision” and toward diagnostic events inside the repo.
For example:
What boundary did the repo show was responsible?
What test actually proves the claim?
What artifact is source truth vs downstream output?
What config or runtime obligation must remain true?
What failure surface shows drift?
What verification result confirms the repo moved closer to coherence?
That is a different kind of state from session memory.
It is less “the model should remember what we decided” and more “the repo should be able to produce governed findings the implementer can act on.”
That distinction matters because operator-side capture can become its own drift surface. If the human captures the wrong abstraction, scopes it too broadly, locks the wrong decision, or fails to update it, the model may become more consistent around the wrong thing.
So I agree with the underlying claim that the model alone cannot be the source of truth.
But I’d frame Scarab as a different answer to that problem:
The coding agent remains the implementer.
The human still gives intent.
Scarab reads the repo and produces repo-grounded findings.
Those findings help govern the lane the agent works inside.
So the question I keep coming back to is:
What truth should be captured by the operator, and what truth should be mechanically surfaced by the repo itself?
Because for autonomous coding agents, I don’t think session continuity is enough. The repo needs its own governed relationship to truth.
Thanks — the layer separation is the move. I hadn't articulated the "capture becomes its own drift surface" risk as sharply until you named it.
Split criterion I keep coming back to: operator captures intent, repo surfaces evidence. If the code can prove it, the operator shouldn't have to remember it. If the code can't recover it, no one else will. Concretely:
Operator-side — the slice code can't surface:
Intent — why this trade-off, not the other. Code shows what, never why.
Rejected paths — considered and dropped. The codebase only contains chosen branches; rejected ones disappear and get re-litigated by the next operator.
Locked invariants — binding decisions that outlive any implementation. "We never X" isn't in the code, but it constrains every PR.
Process state — what's in flight, blocked, waiting on a vendor. The repo has no concept of "thread parked since Tuesday."
Implicit-by-convention — practices that show up as effects in code, never as rules.
Repo-side — your domain, named: boundaries, source-truth chains, test coverage as proof, runtime obligations, drift surfaces between docs/config/code, verification findings.
Where the layers should meet is the handoff. Three interfaces I think both sides need:
Decision → diagnostic peg. A locked decision carries a verifiable_by pointer at the test or scan that confirms it. If the diagnostic breaks, the decision auto-flags as stale instead of silently codifying a lie.
Repo finding → proposed decision. A drift surface in code generates a proposed decision the operator accepts, rejects, or locks. Capture starts from evidence, not memory.
Backward pointer. Every accepted decision points at the artifact that grounded it. Audit trail in both directions.
Honest gap on my side: what I'm shipping today handles operator-side only. The handoff is a feature absence, and the question you closed with is the one I keep parking. For autonomous agents the answer probably isn't either layer alone — it's whether the bridge between them exists. That's the most interesting problem in this space right now.
Yes — I think “operator captures intent, repo surfaces evidence” is a useful split.
Where I’d push the frame one layer further is that Scarab is not mainly about the handoff between notes and diagnostics. That bridge matters, but the larger problem I’m working on is the governance interface between the repo and the AI coding agent.
That is the layer I keep coming back to.
The coding agent should still do what it does best: implement.
The human still gives intent.
But the repo needs a deterministic interface layer that can surface what must remain true before, during, and after the agent acts.
So the question is not only:
What should the operator remember?
Or even:
What should the repo prove?
The deeper question is:
What governed findings does the agent need in order to act without drifting the system?
That is where Scarab is aimed.
A decision record can preserve why something was chosen.
A note store can preserve context across sessions.
A trace can point from intent to artifact.
But Scarab’s lane is repo-side governance: boundaries, source-truth chains, verification findings, drift surfaces, runtime obligations, and evidence-backed repair or build lanes that the coding agent can use without turning the conversation itself into the truth layer.
That distinction matters because the bridge cannot become the governor.
The operator layer can carry intent.
The repo layer can surface evidence.
But the governance layer has to determine what findings are valid enough to constrain agent action.
That is the part I explored more directly in my LinkedIn version of this article, where I framed Scarab less as a diagnostic tool and more as an operating layer for AI agents.
linkedin.com/pulse/i-thought-build...
The larger claim is still the same:
The agent should not have to invent the repo’s architecture every time it opens a task.
And the model alone cannot be the source of truth.
For autonomous coding agents, the missing foundation is not just better memory, better notes, or better continuity.
It is a deterministic governance interface between AI action and repo truth.
Three layers I'll take, with one push back: governance isn't a separate stratum sitting above operator and repo — it's a function that runs across both, and its inputs are deterministic but its threshold isn't.
The deterministic side is what you already named: boundaries, tests, drift surfaces, verification findings. The codebase can produce those without human authorship. But the question „which findings are valid enough to constrain agent action" is policy, not engineering. Coverage at 70 vs 80, a lint warning treated as blocker vs nice-to-have, a failing contract test counted against the build vs flagged — those are calls a human authored once and the governance layer enforces forever. Without that authoring, the same diagnostic surface produces two opposite agent behaviors in two different repos.
So I'd read the stack as: repo surfaces evidence (deterministic), operator authors policy (about which evidence binds), governance mechanically enforces the policy against agent action (deterministic again). The middle step is what keeps governance from being a black box — and it's where the operator-side notes I was describing earn their keep. „We never accept a PR with a regression on contract test X" is intent-as-policy. The codebase can't generate that. The governance layer can't act on it without it.
Which opens the deeper question: how do you stop policy itself from getting rewritten silently? Once policy drifts, the deterministic enforcement on top of it just executes the drift faster and more confidently. Same staleness problem Rapls flagged in the other thread, one layer up. Going to read the LinkedIn longform once the link resolves — the governance framing landed.
I agree that policy has to exist somewhere, and that humans author some of the binding thresholds. But I’d separate policy enforcement from diagnostic governance more sharply.
A coverage threshold, lint blocker, contract test, or “never accept X” rule can constrain action. That is policy.
But Scarab is not only asking whether a pre-authored policy fired.
The diagnostic question is deeper:
Is this evidence actually proving the repo truth it claims to prove?
A test can pass and still be theatrical.
A threshold can be met while the system drifts.
A locked invariant can be stale.
A policy can enforce yesterday’s wrong abstraction.
A scan can surface a signal without explaining whether the system is still coherent.
That is why I don’t treat governance as simply “operator authors policy, repo surfaces evidence, governance enforces.”
For Scarab, the governance interface has to evaluate the relationship between the repo’s truth surfaces, the evidence produced, and the agent action being constrained.
So yes: the operator can author intent or policy.
And yes: the repo can surface deterministic evidence.
But the diagnostic governance layer has to determine whether the evidence is valid, current, truth-bearing, and strong enough to bind the coding agent’s next move.
Otherwise the system is just enforcing drift more confidently.
That is the distinction I’m trying to hold:
Policy can tell the agent what rule to respect.
Diagnostics has to determine whether the rule, evidence, test, boundary, or artifact is still preserving the repo’s actual truth.
That is why I keep framing Scarab as a deterministic governance interface between AI action and repo truth, not simply a policy layer or a handoff between operator memory and repo signals.
Great explanation. I like how you broke down the agent workflow into clear steps. Understanding the thought-action-observation cycle makes AI agents much easier to grasp for beginners.