Inspiration
Code review catches many issues, but intent often gets lost between tickets, prompts, and commits. I wanted a way to convert engineering intent into something testable in CI, so risky or off-scope changes are blocked before merge. Change Contract Enforcer was inspired by that gap: "we said we would do X, but code changed Y."
What it does
Change Contract Enforcer evaluates code changes against a YAML contract and produces a machine-readable verdict (PASS/FAIL + reason). It can enforce rules like dependency change gates, diff-size budgets, and required tests, then fail CI when changes violate contract terms. The result is a policy-driven guardrail that helps teams ship safer, more predictable changes.
How I built it
I built a Node.js CLI (contractctl) with modular evaluators and contract parsing. Contracts are written in YAML, loaded and normalized, then evaluated against repo diffs and metadata. The tool outputs verdict.json for CI automation, and GitHub Actions runs the check on push/PR to gate merges. I also added tests for core evaluators to keep behavior reliable.
Challenges I ran into
One challenge was balancing strict enforcement with developer usability: too strict creates friction, too loose loses value. We also hit CI integration issues (like CLI execution permissions on Linux runners) and had to make invocation resilient. Another challenge was designing contract rules that are expressive but still easy to understand and maintain.
Accomplishments that I'm proud of
I turned a high-level idea into a working, testable enforcement pipeline with real CI gating. The contract model is readable, modular, and easy to extend with new evaluators. I'm proud that the system produces clear verdicts with reason codes, making failures actionable instead of opaque.
What I learned
I learned that “policy as code” is only useful if it’s transparent and developer-friendly. Clear failure reasons matter as much as the rule itself. We also learned to design for CI realities early (execution environment, portability, artifact outputs), not as an afterthought.
What's next for Change Contract Enforcer
Next, I want richer contract rules (ownership checks, file-path scopes, test coverage thresholds, security gates), better PR feedback (inline annotations), and easier onboarding templates. I also plan to improve local developer experience with dry-run modes and contract suggestions, and explore deeper integration with AI-assisted coding workflows so intent and enforcement stay aligned from prompt to merge.
Log in or sign up for Devpost to join the conversation.