{"id":2627,"date":"2026-06-02T03:25:31","date_gmt":"2026-06-02T03:25:31","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/06\/02\/tests-verify-behavior-archmind-verifies-architecture\/"},"modified":"2026-06-02T03:25:31","modified_gmt":"2026-06-02T03:25:31","slug":"tests-verify-behavior-archmind-verifies-architecture","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/06\/02\/tests-verify-behavior-archmind-verifies-architecture\/","title":{"rendered":"Tests Verify Behavior. ArchMind Verifies Architecture."},"content":{"rendered":"
\n
<\/div>\n

The bigger the application becomes, the harder it is to understand this flow.<\/p>\n

Most tooling doesn’t help much.<\/p>\n

PHPStan verifies types.<\/p>\n

Tests verify behavior.<\/p>\n

Code review focuses on diffs.<\/p>\n

But none of them answer a simple question:<\/p>\n

\n

Did the execution architecture of this route change?<\/p>\n<\/blockquote>\n

For example: <\/p>\n

\n
POST \/orders Before: auth tenant middleware DB::transaction Order::create OrderCreated event After: auth tenant middleware Order::create OrderCreated event <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
The transaction disappeared.<\/p>\n
The code still compiles.<\/p>\n
The tests may still pass.<\/p>\n
But the architecture has changed.<\/p>\n
\n
  <\/a> I wanted architecture to become testable <\/h2>\n
Frontend teams have snapshot testing.<\/p>\n
If a UI unexpectedly changes, CI catches it.<\/p>\n
I started wondering:<\/p>\n
\n
What if we could do the same thing for execution architecture?<\/p>\n<\/blockquote>\n
That idea became ArchMind.<\/p>\n
Instead of treating a Laravel project as a collection of files, ArchMind builds an execution graph. <\/p>\n
\n
Route \u2192 Middleware \u2192 Controller \u2192 Service \u2192 Transaction \u2192 Event <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
The graph becomes a baseline.<\/p>\n
Future commits are compared against it.<\/p>\n
If an important architectural component disappears, ArchMind reports a topology regression.<\/p>\n
Example: <\/p>\n
\n
\u2718 TOPOLOGY REGRESSION: POST \/orders lost: transaction_boundary <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
CI fails before the change reaches production.<\/p>\n
\n
  <\/a> What ArchMind actually does <\/h2>\n
  <\/a> 1. Trace execution flow <\/h3>\n
\n
archmind trace --project<\/span> .<\/span> \"POST \/orders\"<\/span> <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
Output: <\/p>\n
\n
POST \/orders \u2514\u2500 auth:sanctum \u2514\u2500 ResolveTenant \u2514\u2500 OrderController::store \u2514\u2500 OrderService::createOrder \u2514\u2500 DB::transaction \u251c\u2500 Order::create \u2514\u2500 OrderCreated <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
This provides a route-level view of the execution path.<\/p>\n
No digging through controllers, services, events, and listeners manually.<\/p>\n
\n
  <\/a> 2. Detect topology regressions <\/h3>\n
\n
archmind verify --project<\/span> .<\/span> <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
Example: <\/p>\n
\n
\u2718 TOPOLOGY REGRESSION Route: POST \/orders Lost: transaction_boundary <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
The goal is not to verify business logic.<\/p>\n
The goal is to verify architecture.<\/p>\n
\n
  <\/a> 3. Surface architecture findings <\/h3>\n
\n
archmind findings --project<\/span> .<\/span> <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
Examples: <\/p>\n
\n
missing_authorization Route is authenticated but no authorization layer was detected. <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
Or: <\/p>\n
\n
transaction_escape Event dispatched from inside a transaction boundary. <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
These findings are intentionally conservative.<\/p>\n
The idea is to surface architectural risks for review rather than claim guaranteed vulnerabilities.<\/p>\n
\n
  <\/a> An unexpected side effect: better AI context <\/h2>\n
Originally, ArchMind was not built as an AI tool.<\/p>\n
It started as a static analysis and architecture verification tool.<\/p>\n
But once an execution graph existed, it became useful for retrieval as well.<\/p>\n
Most AI coding tools work roughly like this: <\/p>\n
\n
Question \u2193 Find similar files \u2193 Send files to LLM <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
ArchMind instead retrieves execution context: <\/p>\n
\n
Question: Why does this payment endpoint sometimes double-charge customers? Relevant context: - transaction boundary - payment event dispatch - after-commit listener <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
In benchmark tests on real Laravel applications:<\/p>\n
\n\n\n\n\n\n\n\n
Metric<\/th>\nArchMind<\/th>\nFile Dump<\/th>\n<\/tr>\n<\/thead>\n
Correct answers<\/td>\n3\/3<\/td>\n1\/3<\/td>\n<\/tr>\n
Average score<\/td>\n76.7%<\/td>\n61.7%<\/td>\n<\/tr>\n
Tokens per query<\/td>\n~700<\/td>\n~9000<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
The interesting result wasn’t just higher accuracy.<\/p>\n
It was that the execution graph compressed architecture knowledge into a much smaller context window.<\/p>\n
\n
  <\/a> How it works <\/h2>\n
At a high level: <\/p>\n
\n
PHP Source \u2193 Tree-sitter parsing \u2193 Laravel-aware analysis \u2193 Execution Graph \u2193 Topology Verification <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
No PHP runtime required.<\/p>\n
Current support includes:<\/p>\n