# SPEC — Charles's MOPAC design brief (verbatim, 2026-08-29 ~02:00 CST)

> Spec of record for the full MOPAC build. Verbatim from Charles (paste).
> Roadmap items become Redmine tickets; this file is the authority.

---

MOPACMeta work stack , the final push. Ran out of quota about 1900 last night. So that forced me to sit down and write this design brief end to end. Much better than feeding you bits at a time.

## Overall architecture / workflow
- Work items are fed in via Redmine , LinkWarden (various tags). This is a kind of "infinite sink" allowing for (low / medium / high ) fidelity capture. It may start low at intake , then get fleshed out via discourse or OpenWebUI discussion. Sometimes a ticket will be very high felt (usually created via AI discussion).
- The MOPAC harness is the part that runs on the two Linux VMs (Ultix-streaming , (one go daemon each in Linux accounts (RCEO, COO,CTO,CCO,BOD) , Ultix-offstage (one go daemon each in Linux accounts RCEO-offstage , chief of staff (cos) Wyble family office , cos personal , cos business). (I plan to get a morning briefing at 0630 CST daily (7 days a week, 365 days a year ) via discourse / redmine / pull request inbox review from all three COS). Exact nature of that TBD. And by the time I'm reviewing things it would have gone through this agent stack: individual contributor builder > individual contributor reviewer > manager review > director review > VP review > SVP review > COO/CTO/CCO (as appropriate) review . Any one of those agents can kick something back down or across.
- All actions in all TSYS software systems are taken via APi via cloudron accounts. So essentially , MOPAC is a (per Linux account) go loop that pulls things from redmine / linkwsrden , does the necessary reduction to practice via LLM / tool calls / LSP etc (documenting / discarding in discourse , tracking work in redmine tickets, sending pull requests in gitea) and connects to LLM via litellm with a back pressure / cost optimization / maximize utility framework and system (described in next section. )
- I've been using crush , with some CLi tooling and screen sessions for a few months , manually monitoring context and compacting. I've built a PMO<->worker model using files for coordination and setuid dirs and "doorbell" protocol . Ifs ... brittle and hacky and I realized that a go system was much cleaner. So I sat down and wrote out this design brief.

## It's a marathon , but it's made up of sprints
- Utilize the z.ai (coding plan) API endpoint for monitoring the usage limits across buckets . Gemini suggested using Redis so that all of the instances (across the seven Linux accounts on two machines ) know the quota / metrics . I dunno if you can centralize that along with LiteLLM? I leave the implementation details up to you.
- Do lighter / smaller (housekeeping / admin etc tasks ) during the peak usage time
- The idea is to maximize usage of the flat rate plan on a 24x7 basis. Utilize the quota bucket usage monitoring. Also use a range of models (4.7, 5.2, 5.3 flash etc ) for bodies of work , tasks , sub tasks , sub agents. The big 5.3 model isn't needed for everything. Especially be aggressive about smaller / cheaper models during peak hours (3x quota penalty). Also , during peak hours , try to perform tasks that are LLM lite but cpu / disk heavy or wall clock runtime heavy. Great time todo things like Redmine ticket cleanup , docker cache cleaning etc etc. also (double check this ) but i believe the peak usage time is 0100 to 0500 CST? Thats when Charles (primary user of this stack ) is asleep. He sleeps 2300 to 0500 CST.
- All users of this stack are located in CST time. So expect things to be pushed into Redmine / Linkwarden during CST daylight hours.
- Redmine has lots of powerful features for dependencies, priorities , due dates etc etc. utilize that functionality heavily when selecting work from the queue every day. Redmine has powerful reporting / filtering functionality , and an agile plugin setup. So use that as a way to have the AI agents (via their cloudron accounts ) and the humans coordinate. Understand that sometimes things in the himab world shift suddenly (say a big deal in the pipeline needs certain prerequisite features). So you may need to scramble to accommodate as best as possible.
- Monitor the load / ram / cpu usage / I/o delay etc for m the system to ensure it doesn't become overwhelmed by builds etc

## Supporting cast and crew

### Sectets management
This is a big one
- Password and keys and 2fa stored only in Bitwarden (Vsultwarden) and Hashicorp Vault . Never on disk.
- Keyproxy application . Backend talks to Bitwarden and Vault (via dedicated go cli/api client) . Frontend is an MCP/APi/cli for the harness. Real keys are never exposed to the harness or LLM. Only placeholder ones.
- Bitwarden holds ssh private keys. Utilize ssh-agent / Bitwarden ssh socket securely to connect to Linux systems

### outbound MCP/CLI to existing systems
Ideally support oauth login to all the below via one time browser flow. Or QR code generation (signal for example I believe uses that)
- Google (docs, tasks , keep, gmail
- IMAP
- Linkwarden
- Google chat
- Signal
- Discord
- Redmine
- Discourse
- Gitea
- Chrome / Firefox / WebKit
- Linux systems ssh/mcp (a large amount of work in the queue is security related , so expect to drive Kali Linux hosted tools , OpenVAS etc )
- REST API
- Cloudron
- HomeAssistant
- Kubernetes

## Inspired by
- AgentZero (https://www.agent-zero.ai)

## Workdlows and use cases
- Beautifoly formatted PDFs of budgets , complex travel itenaries , project plans , project proposals , consulting engagement reports , financial multi year plans , business plans etc Also charts / diagrams. Engineering project documentation.
- Driving GUI desktop software
- Driving REST APIs of multiple software packages to achieve various complex business workflow outcomes
- Producing clean, well maintained , easy to maintain, revenue critical path software packages for TSYS Geoup which provide core business logic via composing / connecting to multiple systems (HyperSwitch , Jenkins , physical systems etc)
- Packaging up over 100 free / libre / opel software projects and deploying onto Cloudron and Kubernetes
- Manage IT infrastructure via IAC (Ansible / AWX / Rundeck / Jenkins / K8S / monitoring systems etc)
- Execute actions on behalf of three chief of staff agents supporting five humans across two different states , multiple lines of business and day jobs (keeping Google tasks / redmine / HomeChart and potentially other management systems in sync)
- Support integration with OpenWebUI for interactive chat sessions (especially for the chief of staff instances). Default to a small / cheap model. Most of the COS interactions will be tossing in tasks or small projects or asking for a report of some kind. However some of them can be complex (like I as CTO discussing one of the line of businesses apps I need to architect and build ) so be able to switch models automatically if needed as the conversational content warrants.
- Crush and GLM5.2 had an amazing rapport and would work for hours and auto compact as they worked. I want that. Some projects and bodies of work are meaty and require a bigger active working memory. Handle that well.
- Provider routing. Some of the work you'll be orchestrating is ITAR or Ts/SCI or proprietary. I have some dedicated OpenWebUI instances for that type of work. That will route to internally hosted models. Very low priority but a key requirement and guideline as you build. I suspect a dedicated high security instance of LiteLLM may be needed for that work?

## Constraints / dev practices / general context
- No python / node / rust
- Go , Java, PHP , C is welcome
- Use docker containers and c groups for all work done on the systems.
- Heavily utilize LSP servers wired into crush
- The MOPAC system should be properly licensed . AGPLv3. Maximally viral. The work it produces will be licensed in a variety of ways.
- I anticipate a monthly AI spend of 200.00. Two 80.00 Z.ai max plans , 40.00 on open router. I can see that shifting to one max plan and rest on open router. So you'll need to be able to support key rotation (I presume LiteLLM handles that). Of course I'll want a full breakdown and analysis of AI usage across COS,BOD,COO,CTO,CCO instances. Via discourse. Generally I want to avoid building custom web UI for things like reporting. Markdown in discourse is a beautiful composable system.

## Roadmap
1. Quota monitoring / back pressure and overall usage management (using existing LiteLLM piece if that's the best course of action. We want to maximize the utility of the coding plan 24x7, especially before 9/22 when I have to move off the legacy plan. Also this is a good place to implement system resource monitoring. If the system is too busy , that's a waste of wall clock time. use c groups for resource control.
2. Model selection matching to phase of task (planning may require using a heavy model (with chunks of the planning process using smaller models). Implementation may be the same.
3. Task management (which items to pickup off queue , monitoring for new ones , handling tickets based on due date / priority / quota availability/ system resource availability

Get to a self hosted core (quota management, model selection, working out of redmine with a go cli) as soon as possible . Build and improve the harness with itself ASAP. You can utilize the existing Redmine CLI on the system to write up (detailed) tickets to get to that self hosted point and then switch to the go Redmine CLi as soon as it works and then ticket up all the above , feed it into your queue and build.

Follow TDD (red / green) and full SDLC best practices. This is the system that will run my (and my inner circle) entire personal and business life. Document as you go (redmine tickets and .md files on disk). Those can be moved to discourse later.

Get this fully delivered by 0630 o m 9/1/2026. I will want to start beta testing it at 0600 CST on 8/31/2026 and need it in full production as of 0630 CST 9/1/2026 (I'll want to get my first briefing via redmine / discourse from all three chief of staff agents at that date / time).

If you need me to connect to signal , discord , google , email, Bitwarden etc , I can do so this evening at 1900.

You are working on ultix-streaming with passeordless sudo and you have ssh to ultix-offstage (as user reachableceo-offstage) which also has passwordless sudo . You also have ssh to all of the COS accounts on ultix-offstage

Here's the linux account list that the harness instances will need to be spun up in:
- Ultix-streaming: reachableceo, TSGBOD, TSGCOO, TSGCTO, TSGCCO
- Ultix-offstage: reachableceo-offstage, COSRCEO-Personal, COSRCEO-Biz, COSWFO