Context
While writing rationale doc comments for the 12 Go modules (task #27), research already surfaced a real example of why this matters: corepack's bundling status changed between when devboost's default was chosen and now (Node is unbundling it starting v25/26), and mise's own docs now discourage the exact direnv integration pattern devboost ships. Neither choice was wrong when made — the ecosystem moved.
The idea
"time has gone since we made our original choices for the 12 apps... I think when we've done our rationales, we really should — per choice — adversarially challenge it, and make sure our weapon of choice is the choice we would do if we had to research the stack today... since that's actually something we should be doing regularly, I wouldn't mind if we made a skill or at least some other kind of process out of it. The whole thing here is people would trust us for the choices to setup a well thought out development environment. New job, new machine, just devboost it and you can start coding in minutes."
Two related but distinct needs:
-
A recurring adversarial-review process (possibly a skill, possibly a scheduled task/cron-style check) that periodically re-researches each module's choice from scratch — as if starting fresh today — and flags where the current default has drifted from what a fresh researcher would pick. This is the same rigor as the "research before defaulting" principle in AGENTS.md, but applied on a cadence to existing defaults, not just new ones.
-
Lifecycle/upgrade visibility when devboost's own opinions change. Per the user:
"we do need to consider lifecycle of our choices. If we change our mind (and we will), a simple run of devboost apply with a new version should update our environment and hopefully tell us what changed (several times even, or at least in a place a developer easily finds)."
This means: when a module's default changes across devboost versions (e.g. delta config tweak, a tool swapped for another), devboost apply on an existing machine should surface what changed and why, not just silently converge to new state. Possibly a per-version changelog surfaced at apply time, or a persistent "recent devboost-driven changes" log the user can review — needs design.
Why this matters for trust
The pitch (per the user) is: "new job, new machine, just devboost it and you can start coding in minutes" — that promise depends on devboost's defaults staying genuinely current, and on users being able to trust that when devboost changes its mind, they'll find out rather than be silently surprised weeks later by unexplained config drift.
Open questions for scoping later
- Cadence: on every module doc-comment touch? Quarterly? Tied to major version bumps?
- Where does "what changed and why" surface — apply output, a CHANGELOG.md, a
devboost changelog command, first-run-after-upgrade banner?
- Should the adversarial-review process itself become the skill from task #28 (module-authoring skill), or a separate one?
- Should re-review results require human sign-off before changing a shipped default, or can devboost auto-adopt research findings (likely: sign-off required, given these are opinionated defaults affecting real machines).
No implementation yet — this is a process/design idea to scope when picked up. Related: task #27 (module rationale docs, where this need first became concrete) and task #28 (module-authoring skill).
Context
While writing rationale doc comments for the 12 Go modules (task #27), research already surfaced a real example of why this matters: corepack's bundling status changed between when devboost's default was chosen and now (Node is unbundling it starting v25/26), and mise's own docs now discourage the exact direnv integration pattern devboost ships. Neither choice was wrong when made — the ecosystem moved.
The idea
Two related but distinct needs:
A recurring adversarial-review process (possibly a skill, possibly a scheduled task/cron-style check) that periodically re-researches each module's choice from scratch — as if starting fresh today — and flags where the current default has drifted from what a fresh researcher would pick. This is the same rigor as the "research before defaulting" principle in AGENTS.md, but applied on a cadence to existing defaults, not just new ones.
Lifecycle/upgrade visibility when devboost's own opinions change. Per the user:
Why this matters for trust
The pitch (per the user) is: "new job, new machine, just devboost it and you can start coding in minutes" — that promise depends on devboost's defaults staying genuinely current, and on users being able to trust that when devboost changes its mind, they'll find out rather than be silently surprised weeks later by unexplained config drift.
Open questions for scoping later
devboost changelogcommand, first-run-after-upgrade banner?No implementation yet — this is a process/design idea to scope when picked up. Related: task #27 (module rationale docs, where this need first became concrete) and task #28 (module-authoring skill).