org-buildout/prompt.md

# Q2 2026 Body of Work

I need to have all COO functions handed off to AI and Albert J Lebsch (aka AJ) (TSYS Group COO) (he has been on standby for a few months as I built out the core IT physical infrastructure) by end of September 2026. 
I MUST be fully in CTO role by October 1st 2026.

AJ has full access to all business/IT systems of TSYS Group. He will be overseeing the AI agents.

Here is the AI team roles/agents that need to be stood up with Cloudron accounts and logged into all role appropriate systems:

## COO 

COO will be the main agent that AJ interacts with day to day. It will serve as his assistant and help him orchestrate all business operations. AJ reports directly to the board of directors, as do I as CTO. We are at the same level of the organization. He handles operations, i handle R&D. I've been handling operations as the founder and am now fully delegating.

### SVP KNEL

SVP KNEL is senior vice president of Known Element Enterprises (KNEL). KNEL runs and owns all IT/business systems and services for TSYS Group. TSYS Group is the name of the overall organization. I need to document in Discourse all of the TSYS Group components and will do so in October when I on-board as CTO fulltime.

Anyway, here are the reports to SVP KNEL. The idea is that SVP KNEL/SVP TCTC will synthesize policy level and strategic information to COO. COO/AJ will make the necessary decisions and also inform/consult the board of directors as necessary.

#### VPTechops
#### VPSecOps
#### VPTechCompliance 

### SVP TCTC 

- VPFinance 
- VPAccounting 
- VPInvesting 
- VPTreasury 
- VPTrading 

# Overall goals for rest of August :

1. Have PFV Proxmox / Network deployment , configuration, tuning completed. Including the deployment of Proxmox onto PFV-tsys2 , and addressing the onsite physical wiring issues. This is the foundation for the heavy compute resources that Known Element Enterprises will provide to TSYS Group . I believe this sub project deliverable is at about 80% done. 

2. Have all “pets” support servers in place (built out through a combination of interactive AI sessions doing work via tickets, using git heavily , documenting in discourse , (in sandbox / preprod ) using Ansible via AWX for the prod tier (and also in the non prod after the core functionally has been validated via iteration) and fully operational. This is : 
    tsys-ca 
    PFV-netinfra-01 and 02 

I believe this is about 80% done. The main remaining deliverable is the (specific) core functionality as IAC portion (and also setting up test environment on preprod-* to test changes (including an isolated proxmox network for DHCP)) and overall (and any service specific) hardending testing on sectestbed-*.

3. Have full up / down alerting , instrumentation coverage of all systems and services. Across 
4. 

## Overall goals for September:

Have all applications and services deployed on Cloudron/K8S

## K8S

See k8s.md for my core notes on k8s for TSYS Group. It needs to be fleshed out in discourse discussion and then turned into redmine tickets for reduction to practice.

## Meta Considerations 

- full SDLC 
- I’m architect / manager / tier 4 technical subject matter expert 
- We’ve been too fast / loose with building out production infrastructure. My fault. Fixing that now 

We are moving into full production / revenue generation operations at PFV. As such, we must adopt proper, best common practices and a full software development/test/release life cycle processes.

Here are my notes on what that looks like for TSYS Group operating with a mix (90% AI agents, 10% humans). This needs to be documented in discourse and reduced to practice via Redmine tickets and code.

- Use atomic commits, conventional style commit messages. Commit often. Push when you have completed a logical unit of work. Develop in main/master. utilize the tea cli tool for making pull requests from main/master branch to release branch. 
I’m open to per project contextualized discussion about branching approaches as needed for that project. Generally , my advice is work smart off main/master only. 
If you want to utilize branches on the workstation to move quickly and have checkpoints , go for it.  Often times it’s faster to use branches to be able to more easily iterate or explore a few ideas or not have to mess around with stashing etc. Generally I dont want multiple branches in git remote, and certainly not without good reason and human approval.

- Ci/cd. Generally I have a strong preference for the local workstation to be able todo whatever ci/cd process is needed as well as (be able to) utilize our gitea ci / cd infrastructure. They should be maintained in lockstep for all projects. The further left we can move ci/ cd , the better. We have a mix of developers and agents. Some running inside the hosted security / convenience boundary , some running on their own beefy workstations. Use docker / kubernetes for everything. It can be a cluster of 1 or 100 just the same. Don’t presume any level of scale. Containers are containers , k8s is k8s. 

- Approval gates , peer review etc

- Redmine is our single system of record for ALL project work. You have access to the redmine-cli tool. Use it. See below for discussion of discourse. Same cultural rules apply here. 

- Discourse is our single system of record for documentation. It’s all markdown. Gitea has been where docs are , alongside code. This isn’t what we do on the engineering side of the house , and I want to stop doing in operations and move to the same model we use in engineering. No gitea .md files , no gitea issues (see previous point about redmine), no gitea wikis. Up to now , git has been your only “api”. You now have the discourse-cli tool , use it. 

- Portability and reproducibility by anyone , not needing awx as a prerequisite requirement (an optional nice to have but not mandatory at least for bootstrap )

- Use status.md instead of storing todos in context / harness todo tool . It’s fine to use the harness todo tool for tracking current work .  (See earlier points about token efficiency). Remember , you fully own status.md. I only consume it. Also, see earlier point about heavily using redmine. Status.md isn’t the system of record. It’s a durable git tracked scratchpad used for token efficency purposes. High fidelity tactical notes as you work for input to commit log / PR / redmine updates. 

- Stop thinking so much on your own. You are not alone. You are my employee. You can ask me for guidance. I want you to work on getting to code/output much faster. Explore with code. Gather ground truth. You are burning tokens way too much for things that can be answered very quickly/easily with code. Also, you need to be very comfortable to ask me questions. Use a questions-v(x).md file that i can review/edit inline. Gathering questions in a git tracked way is imperative. Questions/answers/decisions and context around them is often more important than the code itself. Make sure to capture and synthesize to Discourse/Redmine. Dont over think/self debate/ruminate. Just gather data either from  me , or via code or both. The token burn is totally unacceptable. I have a quota and cant keep burning through it.

- Unless I specifically tell you todo so , never interrupt what you are working on to pivot the whatever thing I tossed to you in another conversation turn. Track it in an inbox section in status.md. If it’s materially different , spin up a redmine ticket. 

- Utilize belt and suspenders approach to protocol enforcement. AGENTS.md , git pre commit / pre push hooks. 

- Run a routine “gardening” loop. I’ve noticed that you tend to sprawl .md files all over the place. You are very disciplined with code , not so much with docs. 

- Keep docs / code / tests in sync at all times. Oh, git .md files can and should exist and be stubs to the relevant discourse urls. 

- Utilize red / green TDD for all code. 

- Utilize linters on all code as soon as possible. Again , be token efficient. Don’t burn tokens parsing huge blocks of code. Farm that out to deterministic tooling. Crush may have LSP wired up for the languages you are working in (both code and docs ). (This includes prose lining , but LSP doesn’t exist for that as far as I know) (so farm out to docker image). If an LSP isn’t wired up, pull a docker image and use it to lint the code. 

- Speaking of docker do all of your development work in a container. Either a custom one , or off the shelf or a mix. You may docker pulll whatever you need without asking me first. Be smart about naming containers. Don’t ever use the default naming method docker uses. Always name it with a project prefix. Use docker compose and have hook scripts to bring up / down. Scan my ~/projects directory for a number of examples of lifecycle scripts we’ve worked on. While your at it , look at the AGENTS.md files as well. Generally my projects follow similar patterns , and I adopt same approaches with a bit of mix and match. 

- Speaking of farming out . Utilize sub agents as you would a sub contractor. Not as staff augmentation , but as a way to get a well defined deliverable in parallel while you do other work. 

- full SDLC support (new trackers / statuses etc )
- Sub projects (IAC, networking , datacenter etc ) 
- Maybe split along CMMC boundaries / IT functional areas and levels (admin / engineer / architect )? 
- Need to think about AI staff (individual Hermes agents ) with cloudron accounts and being scoped to their respective Redmine projects only. 
- We really need an ITSM tool / system / workflow engine (discourse ? Windmill ? Nextcloud ?)
-