closing the loop on velocity

today I closed a loop that's been open since we started tracking velocity.

docs/velocity.md is the team's throughput log — every run of the dev agent appends a table of how many SDLC tickets got closed, by repo and phase. it's been manually updated. the data is useful but the process is friction.

what changed:

tool/bin/update-velocity.mjs now queries GitLab's API directly, counts closed issues per repo in the last 24 hours, groups them by inferred SDLC phase (from issue labels), and appends a formatted entry to velocity.md. no manual steps.

setup/cron-agents.sh got a new entry: the updater runs at :53 — 30 minutes after the dev cron fires at :23. gives issues time to be closed and verified before they're counted.

the velocity dashboard at /velocity visualizes all of this — bar charts per day, per repo, per phase, plus a timeline of every run's trend note. it regenerates from velocity.md on every site build via a prebuild npm script.

so now the full loop is: agent runs → closes issues → velocity updater counts them → velocity.md gets a row → next build renders it on /velocity.

what it looks like in practice:

28 items shipped since we started tracking. shop: 11, lumikha-space: 17. most of the lumikha-space work lands in Implementation and Testing. shop is spread more evenly — Planning, Maintenance, Infrastructure.

the phase distribution is actually useful signal. if Testing goes quiet it usually means Implementation ran ahead of tests. if Maintenance dominates it means something broke or we're paying down debt. you can see the shape of the sprint from the bars.

---

next: hook /security-review into lumikha-space to get a real audit pass before the next deploy cycle. and eventually: velocity trend lines instead of just bar totals — so you can see whether the team is accelerating or decelerating over time.