2026-05-30 18:23:19 +02:00
|
|
|
# ToDo
|
|
|
|
|
|
2026-05-30 18:30:02 +02:00
|
|
|
- [x] Main readme only says ansible, not terraform. Should properbly be included.
|
|
|
|
|
- [x] Main readme does not include a description of the name boma, nor the scope (i.e. infrastructure - not laptops)
|
2026-05-30 18:23:19 +02:00
|
|
|
|
2026-05-30 22:05:40 +02:00
|
|
|
- [x] Method to review repo to ensure
|
2026-05-30 18:23:19 +02:00
|
|
|
- We dont carry around code, comments, notes, etc. that is no longer needed but was perhaps added to fix an issue that has been resolved.
|
|
|
|
|
- That all code, structure, comments, notes etc. follow our design decisions.
|
|
|
|
|
- That clear intent is documented throughout - and that there are not any overlaps, contradictions etc.
|
|
|
|
|
|
|
|
|
|
- [ ] Forgejo CI
|
|
|
|
|
|
|
|
|
|
- [ ] Testing
|
|
|
|
|
- Code testing tools (molecule etc.)
|
|
|
|
|
- AI interpretation of molecule etc, but also actual testing via API-calls, CURL pulls of web products, log reviews and perhaps even headless browsing
|
|
|
|
|
|
|
|
|
|
- [ ] Building stuff
|
|
|
|
|
- How to manage logs
|
|
|
|
|
- How to manage APIs
|
|
|
|
|
- How to import/integrate from baobabAnsibleV4?
|
|
|
|
|
- What to install on nodes?
|
|
|
|
|
- firewalls?
|
|
|
|
|
- apps?
|
2026-05-30 22:05:40 +02:00
|
|
|
- wirering up loki, prometheous, grafana dashboards, grafana alerts, uptimekuma alerts on askari
|
|
|
|
|
- tagging strategy - we need a specific standard so that we can target runs, but dont over-tag.
|
2026-05-30 18:23:19 +02:00
|
|
|
|
|
|
|
|
- [ ] Split horizon FQDN - with or without nyumbani
|
|
|
|
|
|
|
|
|
|
- [ ] Control node
|
|
|
|
|
- Setup and testing while waiting for hardware?
|
|
|
|
|
- Bootstrapping - perhaps dedicated recipe and playbook?
|
|
|
|
|
- Role of mamba? - Access/availability vs compute power and ease?
|
|
|
|
|
- rbw on control node
|
|
|
|
|
|
|
|
|
|
- [ ] Updating
|
|
|
|
|
- Pinning vs latest.
|
|
|
|
|
- services and containers vs packages and builds/github pulls/flatpacks
|
|
|
|
|
- scheduling of updates and reboots - incl. testing afterwards.
|
|
|
|
|
|
|
|
|
|
- [ ] shell setup
|
|
|
|
|
- What does it matter in relations to the AIs work on the control node?
|
|
|
|
|
- What should we set up on the hosts, if i'll rarely go there?
|
2026-05-30 19:01:22 +02:00
|
|
|
|
|
|
|
|
- [ ] Scheduled work
|
|
|
|
|
- /review-repo maybe as claude -p via cron every two weeks?
|
|
|
|
|
- Sanity checks: does a photoprism have its pictures? are email services recieving and sending?
|
2026-05-30 19:17:25 +02:00
|
|
|
- Cron "section": a declarative way for the repo to own which cronjobs are active on a
|
|
|
|
|
host, enforced by Ansible. Sketch (deferred until we have hosts): a `scheduled_jobs`
|
|
|
|
|
role reading a `scheduled_jobs__jobs` list from group_vars/host_vars, rendered via a
|
|
|
|
|
managed /etc/cron.d file. Open Qs: general role vs control-node-only; prune
|
|
|
|
|
undeclared jobs (repo authoritative) vs additive; validate headless email + that
|
|
|
|
|
cron's env has the `claude` CLI. The /review-repo fortnightly job is the first entry.
|
2026-05-30 22:05:40 +02:00
|
|
|
|
|
|
|
|
- [ ] Claude setup
|
|
|
|
|
- superpowers or other methodologies? → decided: brainstorm for intent, capture as
|
|
|
|
|
ADRs (skip plan files); hooks + slash commands + /review-repo for enforcement at scale.
|
|
|
|
|
|
|
|
|
|
- [ ] Kaizen loop — set up ~2026-06-06 (one week from now)
|
|
|
|
|
- Build `/retro`: reads `docs/FRICTION.md` + `/review-repo` recurring findings + a
|
|
|
|
|
tooling-usage inventory; proposes add / change / **remove** (biased to remove);
|
|
|
|
|
records decisions as ADRs; evaluates itself. Recurrence-triggered + light periodic sweep.
|
|
|
|
|
- `docs/FRICTION.md` is live now — keep appending raw signals until the retro consumes them.
|
|
|
|
|
|
|
|
|
|
- [ ] What is the right order of operation when spinning up from scratch? (OS, DNS, authentik, traefik...?)
|
