Of the six keys under reports, three reached the command — prompt, title, labels — and three did not.
enabled — the documented default was the opposite of the behaviour
Documented "Generate reports (default: false)". Read by nothing. The generated workflow ran buddy report --publish every week regardless, so a repository that never opted in got a report issue anyway, and one that set enabled: false got the same.
It can't be enforced in the workflow: a cron trigger has no way to read the config. So the workflow now passes --scheduled, and the command declines to publish on a scheduled run unless enabled is true:
shouldPublishReport({ scheduled: true, enabled: undefined })
// { publish: false, reason: 'reports.enabled is not set — scheduled reports are opt-in' }A person typing buddy report --publish by hand is not second-guessed — they've already decided. The setting governs the run nobody typed.
period — never consulted
const period = (options.period ?? '30d')Now flag → config → default.
schedule — removed rather than wired
Declared as "cron expression for the scheduled run". No production path could ever have honoured it: buddy setup writes the config and the workflow in the same run, from a preset rather than from a config that doesn't exist yet, and generate-workflows doesn't write buddy.yml at all.
A key that no generator reads is a promise the docs can't keep. The cadence lives in the workflow's schedule: block — which the presets docs already say — and enabled's docstring now says so too.
Nothing validates reports, so an existing config carrying the key keeps loading. It just never did anything.
If you'd rather have it work, the honest design is buddy generate-workflows regenerating buddy.yml from the resolved config. That's a feature, not a wire — flagging rather than building it.
Tests
2143 → 2148.
Lint ✓ · typecheck ✓ · check:docs ✓ · 0 fail
🤖 Generated with Claude Code