boma/docs/TODO.md
sjat 11af84938d Add kaizen friction log and schedule the kaizen-loop setup
docs/FRICTION.md: a running log of friction/gotchas/recurring-fixes/unused tooling,
seeded with this session's real signals — raw material for the periodic kaizen
review. docs/TODO.md: schedule building /retro in ~1 week, and record the Claude-setup
decision. (Also carries your earlier backlog edits.)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-05-30 22:05:40 +02:00

3.1 KiB

ToDo

  • Main readme only says ansible, not terraform. Should properbly be included.

  • Main readme does not include a description of the name boma, nor the scope (i.e. infrastructure - not laptops)

  • Method to review repo to ensure

    • 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?
    • 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.
  • 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?

  • 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?

  • 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.

  • 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...?)