Comment by Mihai_LeanZero on "The Tests Passed. The Architecture Didn't."

This tracks with something I've run into building agent tooling for ops workflows: tests catch behavior regressions but never structural ones, and once you're gluing multiple agent-driven changes together the drift compounds quietly. The baseline idea, flag new violations rather than the whole existing debt, is the right call, trying to get a real project to zero first is a nonstarter.

One thing I didn't see addressed: what happens when an agent's change is a legitimate, deliberate refactor that's supposed to move the policy itself, not just violate it. Say a requirement genuinely calls for introducing a new adapter layer that didn't exist before, the agent's diff will look exactly like a violation to Guard (a new import crossing an unapproved boundary) even though it's the correct outcome. Does Guard have any notion of "this change is proposing a policy update" versus "this change breaks an existing rule", or does that always fall back to a human editing the policy file after the fact? That boundary between fact-checking and rule-authoring seems like the part that'll matter most once agents start doing bigger structural work, not just feature slices within an existing shape.

That’s a good distinction, and I think this is actually one of the harder parts of the problem.

In the current version of Guard, a deliberate architectural change is not treated as implicitly changing policy. If an existing rule is violated, Guard will report it even when the change may be intentional. Policy changes are a separate, explicit step.

There is a propose flow that can generate evidence-based rule and contract proposals from the project state, and those proposals still have to be explicitly approved before becoming active policy. So the model is roughly:

change → detect against current policy → decide whether this is a violation or an intentional architecture change → update/approve policy → verify again.

I think keeping that boundary explicit is important. I don't want the agent that made the refactor to be able to silently rewrite the rules it is being checked against.

The part I'm interested in exploring is making that workflow more agent-friendly: letting the agent say “this requirement intentionally changes this boundary,” then having Guard produce a bounded policy proposal for human approval rather than treating it as either a hard failure or an unrestricted policy edit.

That feels like a useful middle ground between fact-checking and rule-authoring.

Search Hashnode