[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@scuffi/gardener@0.1.22

@scuffi/gardener

Each release is a git tag (vX.Y.Z) and the matching @scuffi/gardener version on npm. To move a
connected repository to a release, follow Upgrading.

0.1.22 (2026-10-29)

Patch Changes

• 2545a92: issue.close takes an optional reason, completed or not_planned, which Gardener sends to GitHub as the issue's state_reason. A task can now close an issue it won't fix, or one that no longer applies, as not planned rather than completed. Without reason, GitHub records completed, as before.

0.1.21 (2026-10-28)

Patch Changes

• ba063e1: A task can now start another task with the new task.run effect, so one task's decision can lead straight into the next: a triage task that judges an issue worth fixing can start a fix task on it, and the fix task can start a third that announces the pull request it opened.

  effects:
    - issue.label.add
    - task.run: { tasks: [fix] }

  The model picks one of the listed tasks and the subject: this run's own issue or pull request, or a pull request an earlier step of the plan opens. It's always the plan's last step, at most one per run, and never retried. The apply job starts it by dispatching the target task's workflow, which is why a task that declares task.run gets actions: write on its generated workflow, and only then (see SECURITY.md). A task that only ever runs this way can say which input it takes with the new subject: option on its github.workflow_dispatch trigger (issue or pull_request).

  A started run is not a fresh start. Before dispatching, the Worker records the request, and the started run is admitted only if it matches one: it then inherits the starting run's starter decision (never a wider one) and counts against the first author's runs-per-author, so an outsider's issue can't buy more runs or more trust by chaining tasks. Chains stop at depth 3. A bot's manual run that matches no request, or that carries a prompt, is refused before the model runs.

  Behaviour change: a workflow_dispatch run started by a bot or GitHub App (including another workflow using GITHUB_TOKEN) is now refused unless a Gardener task.run started it. Runs a person starts by hand are unchanged. See docs/operations.md.

  To use task.run, run gardener upgrade: the Worker needs migration 0006, which upgrade applies, and the repository's workflows need this release's pin. gardener generate refuses task.run on a project pinned to 0.1.20 or earlier, and the Worker refuses it at run time for those pins.

0.1.20 (2026-10-27)

Patch Changes

• 4dd5d8a: Tasks no longer write as if they were proposing something. Gardener's instructions to the model described its work as proposals ("you propose, a separate job applies"), and models carried that into the comments, pull request bodies and messages they wrote ("I propose…", "the fix I'd make…").

  The model is now told that it acts by adding steps, that a trusted job applies them in order and stops at the first one that fails, and that text in a repository step is published as written once every earlier step has applied. So it writes the finished reply, in the voice of the team that runs the repository, stating what it verified and decided as fact. It never writes that a later step has happened, and it treats claims in the issue or comment as unverified. Chat messages are described as what they are: one plain-text line, without Markdown or links. The run summary, written before anything is applied, still doesn't claim the steps took effect. Refusals the model reads mid-run use the same language.

  These instructions ship with the deployed Gardener Worker (gardener upgrade). This package also updates the task-authoring guide written to .gardener/SKILL.md, the starter tasks from gardener init and the examples, which now give direct instructions ("Comment once, concisely, with:", "Add at most two labels…") instead of "Propose…".

0.1.19 (2026-10-23)

Patch Changes

• c562405: A commit or merge no longer fails after the model runs npm install. Packages under an ignored node_modules/ often ship their own .gitattributes, and the working-tree capture refused every run that created one. Capture now ignores a new attributes file when Git ignores its directory and nothing tracked lives under it, since it governs no path a capture can include.

  When finish_task fails and the model stops instead of retrying, the run now says so instead of suggesting a higher output-tokens. A refused capture leads the failure message with its reason, is written to the run's audit trail and the Worker logs, and the model is told to fix the cause and call finish_task again.

0.1.18 (2026-10-21)

Patch Changes

• 3269794: - New effect message.send: a task can post one short message about an issue, pull request or discussion to the team's chat. Set the GARDENER_CHAT_WEBHOOK repository secret to a Google Chat or Slack incoming-webhook URL. Only the trusted apply step sees the URL; the model only chooses whether to post and writes a summary of up to 400 characters, which Gardener renders as plain text with links and mentions disabled. Messages are sent after every other effect has applied, at most once per plan for Google Chat and at least once for Slack. A missing secret skips the message without failing the run. Runs started by someone untrusted may only post about what triggered them. A task can't declare both message.send and repository.exec.
  • labeled triggers now fire only when the label just added is one of the trigger's labels-all, so adding an unrelated label to an issue that already carries the trigger label no longer starts another run. Repositories on older workflows get a skip instead of a run for those events once the runtime is upgraded.
  • Upgrading is needed only to use message.send. Rolling the runtime back below 0.1.18 fails in-flight runs that proposed a message.

0.1.17 (2026-10-20)

Patch Changes

• 6bd30e0: - Runs started by someone untrusted are confined to what triggered them. Maintainers, schedules, manual runs and pushes keep today's behaviour; an outsider, a bot (Dependabot's pushes included), a fork head or anyone whose access couldn't be checked gets a run that may act only on the issue, pull request or discussion that triggered it, or on what it creates itself, and may not merge or approve a pull request it opened, edit, publish or delete releases, or re-run checks. Existing repositories get this as soon as the runtime is upgraded.
  • Each task now allows an untrusted starter 3 runs a day by default. A run over the limit finishes as a skip without calling the model. Set limits.runs-per-author to change it (unlimited turns it off), and limits.runs to cap all of a task's runs, maintainers' included.
  • effect-scope: trigger confines every run of a task, maintainers' included.
  • generate warns when a task that non-maintainers can start declares a high-impact effect such as pull_request.merge.
  • Upgrading the repository adds the same scope check at apply time; until then the runtime checks it when steps are proposed and when the plan is built.

0.1.16 (2026-10-19)

Patch Changes

• 066c5e4: gardener doctor --help describes doctor instead of printing deploy's options.
• 1d8ce47: - gardener doctor fails when the installation uses an AI Gateway but the runtime has no gateway token.
  • A failed run's summary counts tool calls refused at the tool-call limit, which never ran, apart from the calls that did.
  • A runtime older than the repository's workflows says to run gardener upgrade when it can't read the runner's event, instead of a schema error.
  • generate and the pull request check refuse more than 100 tasks, the most one sync carries, and any TASK.md over 512 KiB, before compiling anything.
  • The sync waits for a rate-limited runtime's Retry-After, up to 30 seconds, before retrying.

0.1.15 (2026-10-12)

Patch Changes

• eafc338: Tasks can now update open pull requests from a comment. A comment on a pull request, or a manual run against one, checks out its head, so a task can push fixes to it. The new commit.merge_base effect, with the repository.merge_base tool, resolves merge conflicts by adding a merge commit that brings the base branch in, without rewriting history. Projects must run gardener upgrade to use them. git.* includes commit.merge_base only in tasks that declare the tool, so existing tasks keep their bundle.

0.1.14 (2026-10-08)

Patch Changes

• 4775453: The runtime now uses Flue 2.2 and pi-ai 1.0. Run gardener upgrade to deploy it; tasks and their
  workflows don't change.

0.1.13 (2026-10-08)

Patch Changes

• b40c529: connect, deploy and the other commands that write to the Gardener database now pass their SQL to
  Wrangler in a file rather than as an argument. Enrolment SQL carries whole task bundles, so it could
  pass Windows' command-line limit, and some endpoint security tools kill processes started with very
  long arguments.
• 821001c: Tasks now react to the issue, pull request, comment or discussion that started a run: 👀 while
  the task works, then 🚀 if it applied its plan or 😕 if it failed. A run that proposes nothing
  just removes 👀. Reactions only go to authors the task admits, and review submissions get none.
  Two small jobs make them, so generated workflows grant issues: write, pull-requests: write or
  discussions: write for the triggers that need it. Set reactions: false in a TASK.md to turn
  them off. Run gardener upgrade to get them; earlier releases' workflows have no reactions.

0.1.12 (2026-10-07)

Patch Changes

• 653f893: A repository whose .github/workflows/gardener-sync.yml is not Gardener's can name the generated
  sync workflow with "syncWorkflow": "gardener-<name>.yml" in .gardener/gardener.json. generate
  writes the sync workflow there, and connect starts that workflow for the first sync. Gardener's
  own repository needs this, because it publishes the reusable workflow at the default path.
  Upgrading: the field is read by this release's sync and check workflows, so upgrade before adding
  it.

0.1.11 (2026-10-06)

• Every plan and apply job writes a GitHub job summary. Successful runs list the proposed steps,
  then each applied step with a link. Failed runs lead with what happened and what to do: a task
  limit to raise in TASK.md, a temporary provider or GitHub problem to retry, or a plan that went
  stale because the issue or pull request changed. A stale plan needs Re-run all jobs, since
  re-running only the apply job replays the same plan. Each summary ends with the exact
  gardener runs view command for the run.
• New effects pull_request.review_comment.reply and pull_request.review_thread.resolve, so a
  review-fixing task can answer each finding in its own thread and resolve only the threads its
  commit fixed. Both are limited to the pull request that triggered the run.
• Comments, replies and resolves planned after a commit.create in the same run now accept the
  head that commit produced. Before, they only passed because GitHub reported the new head a
  couple of seconds late.
• A review that waited behind an earlier round now plans on the pull request's current head, so it
  sees that round's push instead of stopping on a stale checkout. Fork pull requests are unchanged.
• When a repository and its runtime are on different releases, the runtime's refusal names both
  releases and the fix: gardener upgrade --workspace <name> with the CLI from the newer release.
• A failed run reports why Gardener refused the model's result, or which check the model's finish
  failed, instead of "Flue task execution failed".
• max-tool-calls is documented as including the final finish_task call.
• The reusable workflows use actions/checkout v7.0.1, actions/upload-artifact v7.0.1 and
  actions/download-artifact v8.0.1, which run on Node 24.
• Upgrading: deploy the runtime first (gardener upgrade does), then commit and push the upgraded
  repository. An older runtime refuses tasks that use the new effects.

0.1.10 (2026-10-01)

• authors can be a list of exact GitHub logins, optionally with maintainers, such as
  [maintainers, "devin-ai-integration[bot]"], so a task can respond to a review bot. Logins
  match case-insensitively. Quote [bot] logins inside a bracketed YAML list.
• New opened-by trigger filter: exact logins of who opened the issue, pull request or discussion,
  such as ["github-actions[bot]"] for pull requests Gardener opened. It works on comment, review,
  label and state triggers, and the generated workflow prefilters it.
• New top-level checkout: pull-request-head, so a task can push a commit onto an existing pull
  request's branch. Such tasks run one at a time per pull request.
• Together these let a task answer reviews on its own pull requests in rounds: fix what the review
  found, push one commit, reply, and stop after a set number of rounds. A review starts a run only
  once the pull request's merge ref contains the task's workflow, so update the branch of a pull
  request opened before the task was added.
• init and generate write .gardener/SKILL.md, a guide to the task format for coding agents,
  matching the CLI's version.
• Upgrading: deploy the runtime first (gardener upgrade does), then commit and push the upgraded
  repository. An older runtime refuses tasks that use the new fields.

0.1.9 (2026-10-01)

• Long runs no longer fail with "Subrequest depth limit exceeded". The task agent now pushes its
  result and settlement to the run's session. The session no longer polls the agent while serving
  the agent's tool calls, a loop that deepened the request chain on every tool call until Cloudflare
  refused it. If a pushed settlement is lost, the session checks on the agent itself after three
  quiet minutes.
• A run's tool calls no longer load every earlier result into memory, which could exhaust the
  runtime's memory on long runs with large command output.
• The plan step's max-reconnects now counts only consecutive failed reconnects. The count starts
  again after a connection that stayed up for 30 seconds, and a run allows 50 reconnects in total.
• Upgrading: deploy the runtime first (gardener upgrade does), then commit and push the upgraded
  repository. The runtime fix applies as soon as it is deployed, even before a repository moves to
  this release.

0.1.8 (2026-09-30)

• Tasks set their own limits. Gardener no longer caps max-turns, max-tool-calls, input-tokens
  or output-tokens; it keeps only the minimums a run needs. runtime-seconds may go up to 21,000,
  since a GitHub-hosted job runs for at most 6 hours.
• The plan job's timeout is now the task's runtime-seconds plus 10 minutes, rather than a fixed
  10 minutes.
• Each model request asks for no more output than its model produces (32,000 tokens for gateway
  models the catalog does not list), however large output-tokens is.
• AI Gateway model calls that fail with a network error, HTTP 429 or a 5xx are retried twice, with
  backoff, before the run fails. A retry can be billed by the provider, so output-tokens bounds the
  run rather than the exact spend.
• Upgrading: deploy the runtime first (gardener upgrade does), then commit and push the upgraded
  repository. A 0.1.7 runtime refuses tasks over the old limits. Generating with 0.1.8 in a
  repository still pinned to an earlier release leaves the timeout out, and warns about tasks over
  480 seconds.

0.1.7 (2026-09-30)

• pull_request.open and pull_request.open_draft take optional labels, added right after the
  pull request opens, for example a label another workflow looks for. A task that sets them must
  also declare pull_request.label.add, whether the labels are written out or filled from an
  earlier step. Every label must already exist, and a resumed run adds only the missing ones.
• Existing repositories: run upgrade with this release, then commit and push. The workflows move
  to this release's bridge.

0.1.6 (2026-09-30)

• Non-Workers-AI models (anthropic/…, openai/… and other providers) can go through any AI
  Gateway, including one in another account: deploy --ai-gateway <account-id>/<gateway-id> --ai-gateway-project <name>, with the token from GARDENER_AI_GATEWAY_TOKEN. The token is
  stored only as the runtime Worker's secret. @cf/… models stay on the runtime's own account.
  Later deploy and upgrade runs keep the gateway; --ai-gateway off removes it. See
  AI Gateway.
• A run that cannot reach the gateway, or whose gateway is missing its token, fails with a clear
  message.
• Existing installations: run deploy or upgrade with this release; the new D1 migration is
  applied automatically. Nothing changes until a gateway is configured. The workflows are
  unchanged.

0.1.5 (2026-09-29)

• Runs are no longer refused between an upgrade merging and its sync landing: the runtime also
  accepts task workflows from the release it was deployed from.
• Each run records its tool calls. runs view lists every call with its status and a short
  target (a file path or API route, never command text), and task.settled totals the calls and
  proposals. A failed run's Actions error now ends with those totals, for example
  (16 tool calls: 9 repository.read_file, 7 provider.api.read; no effects proposed).
• upgrade moves package.json scripts that run a pinned @scuffi/gardener, such as
  gardener:generate, to the new release.
• connect starts the sync workflow on the default branch when it is there, so a repository
  merged before connecting gets a green sync.
• --help lists connect, repositories, repository disable|enable and tasks.
• Existing repositories: run upgrade with this release, then commit and push package.json if
  it changed. The workflows are unchanged.

0.1.4 (2026-09-29)

• Pull requests that touch Gardener's files get a Check tasks check. It fails when the
  committed lock or workflows don't match the tasks (a TASK.md edited without generate), or
  when .gardener/gardener.json pins another repository's release, before merge rather than as a
  failed sync afterwards. It runs read-only, with no token and no call to the runtime, so it is
  safe on pull requests from forks. generate adds it to gardener-sync.yml.
• The Release workflow now checks that every input the generated workflows pass is declared by
  the pinned reusable workflows and bridge actions.
• Existing repositories: run upgrade with this release, then commit and push the regenerated
  files.

0.1.3 (2026-09-29)

• Tasks go live when they reach the default branch. generate adds a gardener-sync.yml
  workflow that sends the compiled tasks to the runtime on every push to the default branch that
  touches Gardener's files: new tasks start running, and deleted or drafted tasks stop. connect
  is only needed once per repository. The runtime accepts a sync only from Gardener's pinned sync
  workflow, on the default branch, at the repository's release or the one the Worker runs
  (migration 0003_actions_repository_syncs).
• If the committed files are stale (someone edited a TASK.md without running generate), the
  sync fails and the previous tasks keep running.
• Removed task enable and task disable. To stop a task, delete it or set draft: true. To
  stop everything, gardener repository disable.
• upgrade no longer enrols the repository. Commit and push the regenerated files; the sync
  enrols them.
• A comment author with write or admin access to the repository now counts as a maintainer, even
  if their organisation membership is private. Read-only members still need public membership.
• Existing repositories: run upgrade with this release, then commit and push the regenerated
  files.

0.1.2 (2026-09-28)

• The CLI keeps no local state. It finds an installation by its gardener-<workspace> name on the
  Cloudflare account, and deploy records the runtime URL, CLI version and deployment digest in
  the workspace's D1 (migration 0002_actions_installation). Any operator with access to the
  account can run every command.
• deploy adopts existing gardener-<workspace> resources, and refuses to replace a runtime
  deployed by a newer CLI.
• Removed rollback and down. To go back, release a revert. To remove an installation, delete
  its Worker and D1 database in the Cloudflare dashboard.
• connect no longer rewrites GARDENER_RUNTIME_URL when it is already correct.
• Installations from v0.1.1 or earlier must run upgrade or deploy once with this release
  before other commands work.

0.1.1 (2026-09-28)

• The CLI is published to npm as @scuffi/gardener, so npx @scuffi/gardener generate works
  without a checkout. Tags stage a release through the Release workflow, and a maintainer
  approves it with 2FA.
• Relicensed under MIT, matching cloudflare/computer.

0.1.0 (2026-09-28)

First internal preview.

• Tasks are defined in .gardener/tasks/*/TASK.md. Each runs as its own GitHub Actions workflow:
  planning is unprivileged, and apply executes only the exact, hash-bound plan.
• Effects cover issues (create, comment, label, assign, close), pull requests (open, review,
  comment, label, update, close, merge gated on named checks, and rebase or merge the base in
  through GitHub), branches and commits (limited by branch patterns), discussions, and releases.
• Triggers can filter on labels, branches, mentions and comment authors, or run on a
  schedule.
• Each task can set its model and limits (runtime, turns, tool calls, tokens).
• Refused proposals and failed tool calls are recorded in the run's audit trail (runs view).
• CLI commands: init, generate, deploy, upgrade, yolo, doctor, debug, runs, and
  runs view. The kill switches (task and repository enable|disable) still work but are
  not listed in --help.
• Starter tasks in examples/tasks/: triage, pr-review, mention-reply.