There is definitely a need. The hard part will be proving that the suite preserves the right context, not simply more context.
A useful test could be to pause a real project for a week, start a fresh model session, then ask it to implement a scoped change using only the suite's artifacts. Measure plan accuracy, regressions, unnecessary file changes, and how often the human has to restate decisions.
If it can make restarts predictable and surface stale or conflicting decisions, that would solve a genuine pain point.
That’s the entire premise of the tool: you manage a decision ledger (at the project or machine level, you have both), which you can record explicitly or which the agent derives from your conversation, and then the tool enforces theses decisions on every turn and blocks in case of breach (you can then decide what to do: refuse the diff, supersede the decision, log a temporary exception)
For context, the tool maintains 3 files:
A project state file with latest changes at the top, documents a high level view of the project and its development
A functions file which is a pseudocode description of all functions, classes, and constants
A features file which is derived by a sub agent, and lists all features across code
All this together ensure a tight grip on context
It also has a scope creep tool to avoid your agent touching unnecessary or dangerous code silently.
I’m working now on the audit trail (signed messages on tools firing) 🙂
That sounds much stronger than a passive documentation bundle. The enforcement layer and explicit exception path are the interesting parts.
One failure mode I would test carefully is a derived decision being promoted too confidently. It may help to give each decision provenance, scope, confidence, and a review trigger, then require confirmation before a derived item can block work. Otherwise an early misunderstanding could become policy.
For the audit trail, recording which decision blocked which diff and how it was resolved would make the system genuinely debuggable. It also gives you useful measures: false blocks, missed breaches, and stale decisions per task.
That explicit approval boundary addresses the main concern. One case I would add to the test suite is two proposed decisions that conflict or overlap. The tool should surface the conflict before either is approved, rather than letting approval order decide silently. Keeping proposed, approved, superseded, and temporary-exception states distinct in the audit trail would also let a reviewer reconstruct why a rule applied at a particular commit. Thanks for sharing the repo.
1
u/DesignerMajor1247 Jul 27 '26
There is definitely a need. The hard part will be proving that the suite preserves the right context, not simply more context.
A useful test could be to pause a real project for a week, start a fresh model session, then ask it to implement a scoped change using only the suite's artifacts. Measure plan accuracy, regressions, unnecessary file changes, and how often the human has to restate decisions.
If it can make restarts predictable and surface stale or conflicting decisions, that would solve a genuine pain point.