ArchGuard AI v1.2.0: Transitioning to Interactive ChatOps

finetunedbro98 Beginner 3d ago 126 views 1 likes 2 min read

The core utility of ArchGuard AI has evolved from a static linter into a context-aware architectural assistant through the release of v1.2.0. While the initial release functioned as a Zero-Trust Serverless GitHub Action to detect architectural smells like Mass Assignment or Tight Coupling, the primary bottleneck identified during production usage was the inherent subjectivity of architectural standards. Generic LLM reasoning fails when confronted with team-specific design patterns or mandated response envelopes, leading to a high signal-to-noise ratio.

To mitigate this, I have implemented a ChatOps interface that enables direct interaction within the Pull Request thread. By leveraging the Git Diff and conversation context, the bot allows developers to query the reasoning behind a specific flag. For instance, a developer can invoke @archguard-ai to demand an explanation for a perceived Mass Assignment vulnerability or to request a re-evaluation after a patch is pushed. This transforms the tool from a disruptive automated check into a collaborative agent that mimics a senior architect's peer-review process.

The most significant technical advancement for engineering teams is the introduction of .archguardrules. This feature allows for the formalization of internal technical discipline via a configuration file located in the repository root. By defining explicit constraints, teams can automate the enforcement of specific architectural invariants, such as forbidding direct Mongoose queries within Controller layers or mandating specific JSON response wrappers.

1. All database queries must go through a Service layer. Never query Mongoose directly in a Controller.
2. Do not use standard HTTP responses. All APIs must return data wrapped in { success: true, data: ... }.
3. Never use the Node.js fs module synchronously.

From an infrastructure perspective, the system remains hosted on Cloudflare Serverless to ensure zero cost for the community. To guarantee high availability and prevent regression in the AI gateway's detection capabilities, I have deployed an open-source Daily Health Check CI. This service executes a scheduled dummy PR containing intentionally malformed code to validate that the detection logic remains functional.

Integration requires the following configuration in .github/workflows/archguard.yml to support both standard PR triggers and the necessary issue_comment event for ChatOps functionality:

name: ArchGuard AI Review
on:
pull_request:
types: [opened, synchronize]
issue_comment:
types: [created]

jobs:
review:
runs-on: ubuntu-latest
permissions:
pull-requests: write

For more details, visit:
https://promptcube3.com

aiHelp Neededautomationhelpwebdev

All Replies (3)

F
finetunedbro Beginner 3d ago
Works well for my CI, though I had to tweak the rule sensitivity for some legacy modules.
0 Reply
D
dropout_fan Beginner 3d ago
Setting this up for a large repo sounds like a massive headache. The maintenance effort will outweigh the benefits.
0 Reply
L
lostinlatent Advanced 3d ago
I used something similar for a side project and it saved me from a huge coupling issue.
0 Reply

Write a Reply

Markdown supported