Skip to main content

Bike4Mind bug-a-day (junior IC standing tactic)

What this is. A standing expectation, not a one-week sprint. Every junior single-IC developer at B4M picks one open Bike4Mind issue per day, fixes it, ships it. Always has one in their back pocket alongside whatever else they're working on.

Owners: every junior IC (named below) · Cadence: daily, ongoing · Status: 🌱 standing tactic, getting adopted

Why this matters​

Bike4Mind is the substrate every other product runs on. Polaris, BeeHive, OneBris, OptiHashi, Slack Agent, Mobile, Tavern, Lattice — all of it lives on top of the B4M platform.

Every bug fixed in B4M makes the substrate cleaner. Which means every product built on B4M is cleaner.

The leverage is asymmetric:

  • One hour spent fixing a B4M bug improves 40+ downstream products
  • One day of B4M bug-fixing per IC = ~5–10 substrate improvements per week (depending on the IC count)
  • Compounded weekly, the platform that everything else rides on gets quietly, continuously better

This is the Kernel First operating principle made daily.

The expectation​

  • Cadence: one issue per day, every day, per junior IC
  • Scope: anything in the Bike4Mind issue tracker — the smaller, the better. We are optimizing for cadence, not heroic scope. A 30-line fix you ship today beats a 300-line refactor that sits in a branch.
  • Pattern: pick → fix → ship → next. Always one in flight, alongside your primary project work.
  • Not exclusive of other work. This is the second of your “at least two things a day” (see Multi-Context Velocity operating principle). Your primary assignment continues; the B4M bug rides alongside.

How to make it real​

  1. Each morning, open github.com/MillionOnMars/lumina5/issues, filter by labels — bug, good-first-issue, chore, polish. Pick the smallest one that catches your eye.
  2. Assign it to yourself so the rest of the team sees coverage and doesn't double up.
  3. Fix it. Use the AI augmentation you already use for everything else. Cite the bug number in the PR title.
  4. Ship the PR same day — even if review goes the next morning. The goal is daily issue retirement.
  5. Pick the next one tomorrow.

Why daily and not weekly​

A weekly cadence stops being credible the moment one week gets skipped. A daily cadence has a self-correcting property: a missed day is visible to the IC themselves and to the team. The tactic survives because the cadence is on the order of hours, not days.

Who this applies to​

Every junior single-IC developer. Not optional. Senior leads who already have multi-project context exposure are operating at the Multi-Context Velocity bar at higher scale. Junior ICs use the B4M bug-a-day cadence to build that muscle.

Measurement​

  • Per IC, per week: how many B4M issues retired with your name on the PR
  • Team-wide, per week: total B4M issues closed via bug-a-day vs other sources
  • Substrate trend: open issue count in Lumina5 over time. We want it ratcheting down.

This goes in the weekly engineering review. Not as a perf gate — as a visibility tool. ICs who consistently retire zero are having a conversation, not getting a strike.

Status & next steps​

  1. ✅ Tactic stood up (this page)
  2. ⬜ Announce in #engineering with the cadence ask
  3. ⬜ Confirm which ICs count as “junior single-IC” for this purpose
  4. ⬜ Add weekly count to the standing engineering review agenda
  5. ⬜ After 2 weeks: assess — is the cadence holding? Are issues actually getting retired?