[jtbetz22]

This is a real problem. Hopsule looks interesting.

IIUC, the core of your approach is that decisions get locked as immutable constraints and then served to agents via MCP when they query for context — is that right? Is there anything you can do to ensure that the MCP actually gets called?

I've been experimenting with an approach that triggers a set of checks on the Claude Code stop hook for lightweight, deterministic checks, then does a quick AI-powered review as a pre-commit hook, with a mechanism in place to ensure that appropriate elements of context from repo docs get loaded into context during the review.

One thing I've had to put a good bit of work into is orchestrating what happens when the existing rules don't cover some particular case. How do you think about that?

[cagangedik]

Thanks! You hit the nail on the head with the core approach. But to answer your first question: you can't 100% guarantee the AI will call the MCP. That's exactly why we don't rely on it alone. If the AI skips context, our fail-safes kick in: we track compliance to existing decisions using their IDs directly on file save via our IDE extension, and through our GitHub App on PRs. Regarding your second point on edge cases: when existing rules don't cover a situation, or a PR introduces a new pattern, we extract those changes as DRAFT decisions and leave them for human approval. AI proposes, humans decide. We keep enforcement entirely advisory-only. It warns you, but it never blocks a merge. Advisory-only isn't a compromise; it's the point. We want to make architectural drift visible, not act as a stricter linter. Down the road, if the project grows the way we want, we think the ultimate way to handle this context orchestration might be building our own IDE.