decision-guardian

and reporting what wasn't working. That feedback loop has been more valuable than anything I designed upfront. It also works as an npx CLI for pre-push checks outside GitHub Actions (GitLab CI, Jenkins, CircleCI, local hooks). Repo: https://github.com/DecispherHQ/decision-guardian npm: npx decision-guardian check Would love your feedback

n Guardian posts the relevant decisions as a comment automatically Decision format (plain Markdown): <!-- DECISION-DB-001 --> ## Decision: Use Postgres for Billing *Status*: Active *Severity*: Critical *Files*: - `src/db/*/*.ts` ### Context We evaluated Postgres vs MongoDB. Billing requires ACID compliance. MongoDB was rejected — no transaction guarantees. Features worth calling out: 1) Severity levels (Critical / Warning / Info) — can block PRs on critical violations 2) Advanced matching: glob patterns, regex, content-based rules, boolean logic 3) CLI works with any CI (GitLab, Jenkins, CircleCI, pre-commit hooks) 4) Handles PRs with 3000+ files without OOM 5) Idempotent comments — no spam, updates in place 6) Zero external network calls — nothing leaves your GitHub runner 7) 109 tests, ReDoS protection, path traversal protection vs. CODEOWNERS: CODEOWNERS assigns reviewers. This explains why the review matters. Best used together. vs. Danger.js: Danger requires code. This requires Markdown. Non-JS engineers can own their decisions. It's MIT licensed, single-step GitHub Action or npx decision-guardian CLI. Happy to answer questions. Repo: https://github.com/DecispherHQ/decision-guardian

ected files, it automatically analyzes the diff and drops a structured comment into the Pull Request explaining the context, warnings, and checklists. I just released v1.1, which includes a major internal SOLID refactor. The core engine is now 100% decoupled from GitHub (using ISCMProvider and ILogger interfaces), allowing it to ship as a standalone 430KB CLI (npx decision-guardian check) that works locally, in pre-commit hooks, or on GitLab/Jenkins. Under the hood (How it works): I wanted this to be fast and secure enough to run on massive enterprise repositories, which required a few fun technical implementations: O(1) Pattern Matching: Naively matching N decisions against M files in a 3,000+ file PR is painfully slow. The core engine compiles all file patterns into a Prefix Trie (an Aho-Corasick variant), turning candidate lookup into an O(1) operation relative to the number of decisions. ReDoS-Protected VM Sandbox: For complex rules, you can use Regex to scan diff contents (e.g., detecting hardcoded credentials). Because user-supplied regex can cause catastrophic backtracking, all regex evaluation runs inside an isolated Node VM sandbox with a hard 5-second timeout and pre-flight safe-regex checks. Progressive Comment Truncation: GitHub limits PR comments to 65,536 characters. To prevent failures on massive PRs, the tool uses a 6-layer progressive truncation algorithm that intelligently summarizes details before falling back to a hard truncation. Privacy & Telemetry: I know HN cares deeply about telemetry. v1.1 introduces anonymous usage metrics to help me understand performance (e.g., node version, duration, match counts). However, I designed it with strict privacy constraints: Zero PII: It never collects source code, file contents, repo names, branches, or paths. Runtime Blocklist: The privacy module physically validates every payload against a blocklist before sending. If any blocked field is detected, it throws an error and rejects the payload. Open Source Backend: It is fire-and-forget (never slows down the tool), entirely opt-out (DG_TELEMETRY=0), and the Cloudflare Worker backend code is fully open-source in the repo. Links: Repo: https://github.com/DecispherHQ/decision-guardian Docs/Architecture: https://decision-guardian.decispher.com I also included 5 production-ready templates (security, database, api, etc.) to help teams get started instantly. I’d love to hear your thoughts on the architecture, the Trie implementation, or how your teams currently handle enforcing ADRs during code reviews!

les, Decision Guardian automatically drops a structured comment directly into the code review, giving them the exact context and checklist they need before they merge. Here is a real-world example of how it works: Let's say your team has a strict rule about not breaking public API contracts. The Setup: In your decisions.md file, you create a decision called DECISION-API-001: Public API Contract Protection and map it to the file pattern src/api/v1/*/*.ts. The Trigger: A new developer submits a Pull Request that modifies src/api/v1/users.ts to change how a payload is formatted. The Action: Decision Guardian instantly detects the match and posts a "Warning" comment on the PR stating: "Changes to v1 API routes affect external clients. Before merging: Update API documentation, notify integration partners, and consider a deprecation path". Key Features: You can categorize decisions by severity (Info, Warning, Critical). If a developer violates a "Critical" decision, you can configure the tool to automatically fail the PR status check, preventing them from merging without approval. It runs entirely locally or in your CI/CD pipeline, guaranteeing your source code never leaves your repository. It essentially acts as an automated guardrail, telling your developers why a piece of code is sensitive the exact moment they try to change it. You can check out the repo here: https://github.com/DecispherHQ/decision-guardian

led pair change in the same PR. Regex matching on diffs with ReDoS protection and 5s timeout. { "match_mode": "all", "conditions": [ { "type": "file", "pattern": "src/analytics/events.ts" }, { "type": "file", "pattern": "src/analytics/schema.ts" } ] } That rule fires only when both files are in the same PR diff — the case where a field rename needs to be consistent across both. Tech: TypeScript, Trie for O(1) pattern lookup, safe-regex for ReDoS prevention. CLI is platform-agnostic — GitLab CI, Jenkins, any pre-push hook. GitHub: https://github.com/DecispherHQ/decision-guardian (MIT) Known gaps: PR commenting is GitHub-only for now. GitLab native support is the most requested thing and the ISCMProvider interface is already stubbed for it. Happy to discuss the matching engine or the decision format tradeoffs.

Hub Action 2) AST-based markdown parsing with remark 3) Prefix trie for O(log n) file-to-decision matching instead of brute-force O(N×M) 4) Supports glob patterns, regex content matching (with ReDoS protection via VM sandbox + timeout), and boolean logic for complex rules 5) Handles PRs with 3000+ files using streaming mode 6) Idempotent comments—updates existing ones instead of spamming, with self-healing duplicate cleanup 7) 5-layer progressive truncation to always fit within GitHub's comment size limit 8) No external network calls, no data leaves your GitHub runner What I'd love feedback on: 1) Is the decision file format (structured markdown) the right choice, or would YAML/TOML be better? 2) Any thoughts on content-based matching (detecting patterns in diffs, not just filenames)? 3) Would integration with existing ADR tools (like adr-tools) be useful? Code: https://github.com/DecispherHQ/decision-guardian Happy to answer any questions about the implementation.