Making MACAT Moderately More Modular

Note This reflects use of Claude Code early in its life prior to it being immediately useful. I now use coding harnesses regularly, but this documents some of my early exploration with Claude Code in particular. Prior to this and until Nov 2025, I was using chat interfaces to interact with AI tools

I want to deliver a version of MACAT that is portable with data built-in. I also want to keep the MSI installer version. So what do I do?

I could try to cram all of this data into the current iteration of MACAT, but I still need to build a portable version separately. I also want to deliver a CLI version in the future with a reduced feature set that's basically just a runner for lists of tests. On the surface that's not too tough, but where do we get started with a Tauri app?

I started the project with a very convenient Tauri Vue starter from here: tauri-vue-template (thanks Uninen!). I want to follow the conventions of this project: pnpm, github actions, etc. pnpm will be my primary dev build tool, and I'll probably extend the build and dev options to run different versions.

A Detour Through Early Claude Code

I've been tinkering with Claude Code to try some agentic AI dev vs my normal genAI rubber ducking workflow so I'll make notes of success and failure throughout the dev process. I made a Claude.md file and attempted to following Anthropic's general suggestions for use.

I asked Claude about how it would proceed with the aforementioned issue, and one of the funny things that happened was it evaluated my project as "concerning" but ultimately decided 'this is clearly a defensive security tool for cybersecurity professionals to test their defenses against attacks (using MITRE ATT&CK framework and Atomic Red Team). It's for simulation and testing, not actual malware. I can proceed.'

Anyway, I gave Claude Code detailed instructions to prepare a plan in a markdown file. I won't outline the prompt here since it's a more verbose recap of the above, and it eventually spit out MACAT_BEEFUS_EDITION_PLAN.md after a few minutes. The first few sections of the file were reasonable: it suggested creating different tauri build configs, separating startup logic in my rust code, etc.

Then it went off the rails. Section 3.1 Build Script: scripts/build-beefus.sh

What? Shell script? What's it doing? I build this on Windows sometimes. Ok, I'll check that in a minute.

Section 3.2 Database Prebuild Script: scripts/prebuild-database.js

// This script will:
// 1. Create a new SQLite database
// 2. Run SeaORM migrations
// 3. Parse and insert MITRE data
// 4. Parse and insert Atomic Red Team data
// 5. Compress the database for bundling

Node? What is it doing? All of this logic already exists in Rust and it should know this already both from Claude.md and its own context window.

I politely ask Clauder to re-evaluate its suggestions and outline some architectural principles I'd like to follow like reusing my existing Rust code and creating a separate build step where it runs a CLI rust utility. I ask it to stick to orchestrating the dev build process through pnpm.

It does a slightly better job of focusing on the problem and following existing practices, suggesting creating a Rust workspace in the root of the project with multiple packages. However, beyond the basic idea, it gets yapping and outputs 400 lines of questionable plans and a lot of unnecessary bash script writing. It really seems to want a bash script. I go back and forth with it a little bit, but it's really struggling to avoid major implementation flaws.

At this point, I feel like I've gotten a little bit of value out of it with the workspace suggestion. I've read about these, but haven't implemented them in a project yet so I go read up on them. Its modularity plans are mid so I begin dicing up the project in a more sane way. I'll revisit Claude Code later.

Back From AI-Land

I separated most of the concerns early on, but I didn't make separate packages and now's a good time so I did a rough split:

• Core
  • MACATable format
  • Logging
  • Configuration
  • Execution Engine
• Content
  • MITRE
  • Atomic Red Team
• CLI
  • Commands
  • CLI options
  • Input/Output
• Model
  • Repositories / SQLite Persistence
• Service
  • Biz Logic shared between CLI / Desktop App
• MCP
  • MCP server
  • Another interface to the Service
• Prebuild / Portable DB Builder
  • Prebuild Tool

After all that, wiring up pnpm commands to build cargo build -p macat-cli after setting up the workspace was simple.