ACME's modular architecture

TL;DR I’m declaring ACME’s MVP is done: I’m using it to track tickets, and have imported all my Linear issues. While extending its featureset is not urgent, the modular architecture should allow to me add new features without too much effort. I’ll deploy it to my Mac Studio so that it’s running as a full service.

---

MVP Complete

An MVP of “ACME: A Context Management Experiment” is now complete. Most importantly, the ticketing system works including the automated import of all my Linear tickets. That’s the core deliverable, so the immediate next steps will just be to deploy that to my Mac Studio so that I’ve got it running as a service.

It’s basic but also a nice illustration of the joys of coding agents: you can build a tool for yourself that contains just the exact functionality you use on a more capable platform like Linear. Less functionality, but precisely tailored to fit.

Product overview

To close out the development work, let’s summarise the core design of ACME. Since it’s a revival of old code, I got some additional features “for free” when porting across to the new stack. These aren’t actively used, but did provide a handy set of test cases for ensuring sure that the modular design was working.

Here are the main concepts:

• The foundation is a knowledge graph, implemented as a Postgres database. Nodes, edges, types and properties provide a dynamic schema.
• On top of that foundation is a backend server and frontend web app (ie a typical web stack)
• The primary interface is the CLI tool, suitable for agents. Mostly I’m only using the web app as a read only interface.
• End user functionality is added in the form of modules. These define their own node and edge types, and can install a tabbed page of web components to support their particular requirements.

Modules

Programmes

The screen shot at the top of the article is taken from the Programmes module. Or Programs, for my American friends. Its node types are Programmes, Projects, Milestones, Tickets, a fairly typical work breakdown structure. It also has PRD nodes, as a catch all node to contain a planning doc.

Its UI provides Kanban and Tree views of the data, as familiar interfaces for this kind of data.

Engineering

The engineering module is intended to track documents and context that doesn’t live in the repo, such as research. I’m also considering using it to build an architectural model of an application, similar to the C4 modelling approach

Research Landscapes

The Landscapes module is focused on generating market landscape reports, of which there are many in tech! It is also intended to provide more user friendly output than raw network graph visualizations - a typical landscape report is really just a table with a few category columns.

It’s on my long term to-do list rather than a priority, but this module would integrate nicely with a research agent populating and updating the database.

Next steps

On ACME itself, I’ve no plans to add more features until I’ve been using it for a while to manage my larger Mock Machines project. I’d like a nice system for managing product requirements, architecture decisions, the capability map, to meet the original goal of a capable context management system for coding agents. In terms of simply shipping more and/or better code, though, I think that the bigger wins will be improving the docs and experimenting with the harness rather than the ticketing system.

As a general purpose productivity tool, though, I might do bits and pieces as time allows. As a quick list of ideas:

• Tidy up the code and documentation, so I can share that online. It’s been a good experience working with Mojo, or “Python that compiles”. I built an OpenAPI spec generator and a PostgreSQL driver, which could potentially be useful for others.
• Give the design and widgets an overhaul. For instance, I don’t really find network graph visualizations that useful in practice. But they’re kinda cool, and my vibe coded basic version in the admin module sucks. Deserves an upgrade!
• Make the Landscapes module a real tool. The original idea was building and maintaining market landscapes diagrams, as a visualization layer over a research agent. I don’t have a specific driver for this but the idea still appeals to me.
• Built an integration with Astro and/or Starlight. After I did the Professional AI program at Stanford, I took some of my notes and converted them into a website: https://deeplearning.jonwalls.dev/ . It’s not particularly difficult to map a knowledge graph to a file system, so potentially ACME becomes a way to manage web content. Or conversely, a web site becomes a way to publish a view of the knowledge graph.

For now however - the job is done and the app is ready for production!