Skip to content

fix(reports): honour reports.enabled and reports.period, drop the key nothing could read - #1429

Merged
glennmichael123 merged 1 commit into
mainfrom
fix/reports-config
Aug 29, 2026
Merged

fix(reports): honour reports.enabled and reports.period, drop the key nothing could read#1429
glennmichael123 merged 1 commit into
mainfrom
fix/reports-config

Conversation

@glennmichael123

Copy link
Copy Markdown
Member

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

https://claude.ai/code/session_01UWouahBJT3msK7V2VDYY6T

… nothing could read

Of the six keys under `reports`, three reached the command β€” `prompt`,
`title` and `labels` β€” and three did not.

`enabled` was documented "Generate reports (default: false)" and read by
nothing. The generated workflow ran `buddy report --publish` every week
regardless, so the documented default was the opposite of the behaviour: a
repository that never opted in got a report issue anyway, and one that set
`enabled: false` got the same.

It cannot be enforced in the workflow, because 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`. A person
typing `buddy report --publish` at a terminal is not second-guessed β€” they
have already decided, and the setting exists to govern the run nobody
typed.

`period` fell back straight to `'30d'`, so the config's value was never
consulted; the flag wins, then config, then the default.

`schedule` is removed rather than wired. It was declared as "cron expression
for the scheduled run", and 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 does not exist yet, and
`generate-workflows` does not write `buddy.yml` at all. A key that no
generator reads is a promise the docs cannot keep. The cadence lives in the
workflow's `schedule:` block, as the presets documentation already says, and
`enabled`'s docstring now says so too. Nothing validates `reports`, so an
existing config carrying the key keeps loading; it simply never did
anything.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UWouahBJT3msK7V2VDYY6T
@glennmichael123
glennmichael123 merged commit f5adb6d into main Aug 29, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant