{"owner":"hashicorp","repo":"packer","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\n## Purpose\n\nPacker is HashiCorp's open-source (BUSL-1.1) CLI for building automated machine\nimages. It is a Go program that orchestrates pluggable **builders**,\n**provisioners**, **post-processors**, and **data sources** through the\n`hashicorp/packer-plugin-sdk`, driven by HCL2 templates (legacy JSON templates are\nstill supported). There is no database, no gRPC/gateway service, and no protobuf\nAPI surface in this repository.\n\nUse this file as the repo-specific operating contract. Prefer the existing `make`\ntargets and established patterns over invented workflows.\n\n## Default Working Mode\n\n- Keep chat concise. Share decision-worthy context, short progress updates, and\n  summarized command output; do not paste large logs or diffs unless asked.\n- Lead with the answer or outcome. Skip motivational filler and obvious recaps.\n- Start broad, unclear, or \"review/investigate/audit\" tasks with read-only\n  discovery and report findings before editing.\n- Ask for confirmation before non-trivial implementation when there are multiple\n  viable approaches, the request is ambiguous, or the change touches the plugin\n  SDK boundary, HCL2 template parsing, the command surface, CI/release workflows,\n  or security-relevant behavior.\n- Proceed without another confirmation when the user explicitly asks to implement,\n  fix, add, remove, regenerate, or run an approved command, or for trivial typo,\n  formatting, or docs cleanup.\n- When blocked by missing credentials, cloud access, or unclear intent, stop and\n  ask. Do not improvise around those blockers.\n\n## Scope And Boundaries\n\n- Work only inside this repository unless the user explicitly requests cross-repo\n  changes (e.g., the plugin SDK or a specific plugin repo).\n- Do not read from, write to, or execute files outside the workspace, including\n  `/tmp`, `~`, or `/etc`. Create temporary artifacts inside the repository only.\n- Treat files marked `// Code generated ... DO NOT EDIT` as derived output. Change\n  the source struct/`//go:generate` directive and regenerate; never hand-edit the\n  generated file. This includes `*.hcl2spec.go` and `*_enumer.go`.\n- Do not hand-edit vendored content, `go.sum`, or other generated artifacts unless\n  the task is explicitly about that output.\n- Do not access production systems, cloud consoles, Vault, 1Password, or cloud\n  accounts unless explicitly asked and safely configured. Acceptance tests boot\n  real infrastructure and may cost money — never run them without explicit intent.\n- Do not inspect, print, copy, or persist secrets from shell history, env vars,\n  `.envrc`, CI configuration, or credential stores.\n- Do not run destructive git or remote-system actions without explicit approval.\n\n## Approved Commands\n\nRun `make help` to list targets. Common ones:\n\n### Build\n\n- `make dev` builds and installs a development binary to `bin/packer` (requires a\n  prerelease tag in `version/version.go`).\n- `go build -o bin/packer .` is the minimal build if `make` is unavailable.\n\n### Generate\n\n- `make generate` runs `go generate ./...` to rebuild dynamically generated code\n  (HCL2 specs via `packer-sdc mapstructure-to-hcl2`, enumer output, fixer\n  deprecations). Run this after changing any config struct or adding a component.\n- `make generate-check` verifies generated code is up to date (fails on drift).\n\n### Format & Lint\n\n- `make fmt` runs `go fmt ./...`; `make fmt-check` fails if code is not formatted.\n- `make lint` runs `golangci-lint` over the repo (config in `.golangci.yml`). Use\n  `PKG_NAME=<dir> make lint` to scope. `make ci-lint` lints only newly changed\n  files against `origin/main`.\n\n### Test\n\n- `make test` runs unit tests (`go vet` + `go test`, 3m timeout). Prefer\n  `TEST=./path/... make test` or `TESTARGS=\"-run TestName\" make test` to scope.\n- `make testrace` runs unit tests with the race detector.\n- `make testacc` runs acceptance tests with `PACKER_ACC=1`. **These are slow, boot\n  real machines/cloud resources, and can cost money.** Only run when the user\n  explicitly asks and prerequisites are configured.\n\n## Architecture Rules\n\n- Components are plugins behind SDK interfaces. New behavior belongs in the right\n  component type: **builders** create machines/artifacts, **provisioners** run\n  against a machine via a **communicator** (SSH/WinRM/Docker), **post-processors**\n  transform/act on artifacts, **data sources** fetch inputs. Prefer post-processors\n  and provisioners for cross-builder (\"plugin-independent\") features, since they\n  operate on the SDK's `Artifact`/`Communicator` abstractions rather than a\n  specific builder.\n- Component config is defined by a Go struct plus a generated `*.hcl2spec.go`.\n  After editing config fields, run `make generate` and commit the regenerated file.\n- Keep changes backward compatible for existing templates. New fields must be\n  optional with sensible defaults; do not change the meaning of existing fields.\n- HCL2 parsing lives in `hcl2template/`; the CLI commands live in `command/`;\n  template fixers live in `fix/`. When adding a command, register it in\n  `commands.go`. When deprecating/renaming config, add a fixer.\n- Pass `context.Context` through build/orchestration and network-facing paths.\n- Use the SDK's existing helpers and error patterns instead of ad hoc equivalents.\n\n## Go Style\n\n- Follow standard Go formatting and the repository linter (`.golangci.yml`).\n- Every Go/HCL source file carries the copyright + `SPDX-License-Identifier:\n  BUSL-1.1` header (managed by `copywrite`, config in `.copywrite.hcl`). New files\n  must include it.\n- Keep packages lowercase and concise; export names only when they must cross a\n  package boundary.\n- Use domain terms already present in the repo: `builder`, `provisioner`,\n  `post-processor`, `datasource`, `communicator`, `artifact`, `template`,\n  `plugin`, `fixer`, `hcl2template`.\n- Return wrapped errors with useful context and preserve the original error.\n- Match surrounding struct layout, constructors, and table-driven test style.\n\n## Testing And Validation\n\n- Run the narrowest test set that proves the change, then broaden when the blast\n  radius justifies it (`TEST=./command/... make test`, then `make test`).\n- For PR-bound changes, run the applicable repo maintenance targets before\n  handoff: `make fmt` for Go edits, `make generate` plus `make generate-check`\n  when source changes affect generated files, and `make ci-lint` when the\n  change should satisfy the same lint expectations as CI. If one of these is\n  skipped, state why.\n- Add or update unit tests for behavior changes. If a bug fix is not covered,\n  explain why in the handoff.\n- After changing config structs or adding components, run `make generate` and\n  `make generate-check` so generated code stays in sync.\n- Do not leave formatting or generated-file drift for the user to discover at\n  push or review time; run the relevant `make` target and include the resulting\n  updates in the same change.\n- Do not run acceptance tests (`PACKER_ACC=1`) casually — they are slow and may\n  provision billable resources. State when validation was skipped and why.\n\n## Review Guidelines\n\nPrioritize findings over summary; do not edit unless asked.\n\n- Check correctness first: behavior, edge cases, regressions, nil handling,\n  context handling, and backward compatibility for existing templates.\n- Check that config changes are additive and that defaults preserve prior behavior.\n- Check that generated code (`*.hcl2spec.go`, enumer output) was regenerated when\n  its source changed — flag generated-code drift.\n- Check new commands are registered in `commands.go` and deprecations have fixers.\n- Check tests cover the changed behavior, not just compilation.\n- Flag risky changes to CI, release (`.release/`), CODEOWNERS, or security scanning\n  unless they are the explicit task.\n\n## Commit And PR Guidelines\n\n- Do not commit, branch, push, or open PRs unless explicitly requested.\n- Keep commits focused and logically atomic; use short imperative subjects.\n- Separate regenerated output from behavioral changes where it can be done cleanly.\n- Follow `.github/PULL_REQUEST_TEMPLATE.md`. PR text should say what changed and\n  why, and note any backward-compatibility impact on existing templates.\n- Add a changelog note (`CHANGELOG.md`) for user-facing changes.\n- Never include secrets, tokens, or credentials in commits, PR text, or logs.\n\n## Completion Checklist\n\nBefore finishing a task, verify the following when applicable.\n\n- Source-of-truth files were changed instead of generated output.\n- Applicable repo maintenance commands were run before handoff: `make fmt` for\n  Go edits, `make generate` and `make generate-check` for generated-code\n  changes, and `make ci-lint` for PR-relevant lint validation, or the reason\n  they were skipped is documented.\n- `make generate` was run when config structs or components changed, and the\n  regenerated files are committed.\n- Relevant unit tests and `make fmt-check` / `make lint` were run, or the reason\n  they were not run is documented.\n- New commands are registered in `commands.go`; deprecations have fixers.\n- SPDX/copyright headers are present on new source files.\n- Final handoff states what changed, what was validated, and any remaining risk or\n  follow-up."},"files":{"AGENTS.md":"# AGENTS.md\n\n## Purpose\n\nPacker is HashiCorp's open-source (BUSL-1.1) CLI for building automated machine\nimages. It is a Go program that orchestrates pluggable **builders**,\n**provisioners**, **post-processors**, and **data sources** through the\n`hashicorp/packer-plugin-sdk`, driven by HCL2 templates (legacy JSON templates are\nstill supported). There is no database, no gRPC/gateway service, and no protobuf\nAPI surface in this repository.\n\nUse this file as the repo-specific operating contract. Prefer the existing `make`\ntargets and established patterns over invented workflows.\n\n## Default Working Mode\n\n- Keep chat concise. Share decision-worthy context, short progress updates, and\n  summarized command output; do not paste large logs or diffs unless asked.\n- Lead with the answer or outcome. Skip motivational filler and obvious recaps.\n- Start broad, unclear, or \"review/investigate/audit\" tasks with read-only\n  discovery and report findings before editing.\n- Ask for confirmation before non-trivial implementation when there are multiple\n  viable approaches, the request is ambiguous, or the change touches the plugin\n  SDK boundary, HCL2 template parsing, the command surface, CI/release workflows,\n  or security-relevant behavior.\n- Proceed without another confirmation when the user explicitly asks to implement,\n  fix, add, remove, regenerate, or run an approved command, or for trivial typo,\n  formatting, or docs cleanup.\n- When blocked by missing credentials, cloud access, or unclear intent, stop and\n  ask. Do not improvise around those blockers.\n\n## Scope And Boundaries\n\n- Work only inside this repository unless the user explicitly requests cross-repo\n  changes (e.g., the plugin SDK or a specific plugin repo).\n- Do not read from, write to, or execute files outside the workspace, including\n  `/tmp`, `~`, or `/etc`. Create temporary artifacts inside the repository only.\n- Treat files marked `// Code generated ... DO NOT EDIT` as derived output. Change\n  the source struct/`//go:generate` directive and regenerate; never hand-edit the\n  generated file. This includes `*.hcl2spec.go` and `*_enumer.go`.\n- Do not hand-edit vendored content, `go.sum`, or other generated artifacts unless\n  the task is explicitly about that output.\n- Do not access production systems, cloud consoles, Vault, 1Password, or cloud\n  accounts unless explicitly asked and safely configured. Acceptance tests boot\n  real infrastructure and may cost money — never run them without explicit intent.\n- Do not inspect, print, copy, or persist secrets from shell history, env vars,\n  `.envrc`, CI configuration, or credential stores.\n- Do not run destructive git or remote-system actions without explicit approval.\n\n## Approved Commands\n\nRun `make help` to list targets. Common ones:\n\n### Build\n\n- `make dev` builds and installs a development binary to `bin/packer` (requires a\n  prerelease tag in `version/version.go`).\n- `go build -o bin/packer .` is the minimal build if `make` is unavailable.\n\n### Generate\n\n- `make generate` runs `go generate ./...` to rebuild dynamically generated code\n  (HCL2 specs via `packer-sdc mapstructure-to-hcl2`, enumer output, fixer\n  deprecations). Run this after changing any config struct or adding a component.\n- `make generate-check` verifies generated code is up to date (fails on drift).\n\n### Format & Lint\n\n- `make fmt` runs `go fmt ./...`; `make fmt-check` fails if code is not formatted.\n- `make lint` runs `golangci-lint` over the repo (config in `.golangci.yml`). Use\n  `PKG_NAME=<dir> make lint` to scope. `make ci-lint` lints only newly changed\n  files against `origin/main`.\n\n### Test\n\n- `make test` runs unit tests (`go vet` + `go test`, 3m timeout). Prefer\n  `TEST=./path/... make test` or `TESTARGS=\"-run TestName\" make test` to scope.\n- `make testrace` runs unit tests with the race detector.\n- `make testacc` runs acceptance tests with `PACKER_ACC=1`. **These are slow, boot\n  real machines/cloud resources, and can cost money.** Only run when the user\n  explicitly asks and prerequisites are configured.\n\n## Architecture Rules\n\n- Components are plugins behind SDK interfaces. New behavior belongs in the right\n  component type: **builders** create machines/artifacts, **provisioners** run\n  against a machine via a **communicator** (SSH/WinRM/Docker), **post-processors**\n  transform/act on artifacts, **data sources** fetch inputs. Prefer post-processors\n  and provisioners for cross-builder (\"plugin-independent\") features, since they\n  operate on the SDK's `Artifact`/`Communicator` abstractions rather than a\n  specific builder.\n- Component config is defined by a Go struct plus a generated `*.hcl2spec.go`.\n  After editing config fields, run `make generate` and commit the regenerated file.\n- Keep changes backward compatible for existing templates. New fields must be\n  optional with sensible defaults; do not change the meaning of existing fields.\n- HCL2 parsing lives in `hcl2template/`; the CLI commands live in `command/`;\n  template fixers live in `fix/`. When adding a command, register it in\n  `commands.go`. When deprecating/renaming config, add a fixer.\n- Pass `context.Context` through build/orchestration and network-facing paths.\n- Use the SDK's existing helpers and error patterns instead of ad hoc equivalents.\n\n## Go Style\n\n- Follow standard Go formatting and the repository linter (`.golangci.yml`).\n- Every Go/HCL source file carries the copyright + `SPDX-License-Identifier:\n  BUSL-1.1` header (managed by `copywrite`, config in `.copywrite.hcl`). New files\n  must include it.\n- Keep packages lowercase and concise; export names only when they must cross a\n  package boundary.\n- Use domain terms already present in the repo: `builder`, `provisioner`,\n  `post-processor`, `datasource`, `communicator`, `artifact`, `template`,\n  `plugin`, `fixer`, `hcl2template`.\n- Return wrapped errors with useful context and preserve the original error.\n- Match surrounding struct layout, constructors, and table-driven test style.\n\n## Testing And Validation\n\n- Run the narrowest test set that proves the change, then broaden when the blast\n  radius justifies it (`TEST=./command/... make test`, then `make test`).\n- For PR-bound changes, run the applicable repo maintenance targets before\n  handoff: `make fmt` for Go edits, `make generate` plus `make generate-check`\n  when source changes affect generated files, and `make ci-lint` when the\n  change should satisfy the same lint expectations as CI. If one of these is\n  skipped, state why.\n- Add or update unit tests for behavior changes. If a bug fix is not covered,\n  explain why in the handoff.\n- After changing config structs or adding components, run `make generate` and\n  `make generate-check` so generated code stays in sync.\n- Do not leave formatting or generated-file drift for the user to discover at\n  push or review time; run the relevant `make` target and include the resulting\n  updates in the same change.\n- Do not run acceptance tests (`PACKER_ACC=1`) casually — they are slow and may\n  provision billable resources. State when validation was skipped and why.\n\n## Review Guidelines\n\nPrioritize findings over summary; do not edit unless asked.\n\n- Check correctness first: behavior, edge cases, regressions, nil handling,\n  context handling, and backward compatibility for existing templates.\n- Check that config changes are additive and that defaults preserve prior behavior.\n- Check that generated code (`*.hcl2spec.go`, enumer output) was regenerated when\n  its source changed — flag generated-code drift.\n- Check new commands are registered in `commands.go` and deprecations have fixers.\n- Check tests cover the changed behavior, not just compilation.\n- Flag risky changes to CI, release (`.release/`), CODEOWNERS, or security scanning\n  unless they are the explicit task.\n\n## Commit And PR Guidelines\n\n- Do not commit, branch, push, or open PRs unless explicitly requested.\n- Keep commits focused and logically atomic; use short imperative subjects.\n- Separate regenerated output from behavioral changes where it can be done cleanly.\n- Follow `.github/PULL_REQUEST_TEMPLATE.md`. PR text should say what changed and\n  why, and note any backward-compatibility impact on existing templates.\n- Add a changelog note (`CHANGELOG.md`) for user-facing changes.\n- Never include secrets, tokens, or credentials in commits, PR text, or logs.\n\n## Completion Checklist\n\nBefore finishing a task, verify the following when applicable.\n\n- Source-of-truth files were changed instead of generated output.\n- Applicable repo maintenance commands were run before handoff: `make fmt` for\n  Go edits, `make generate` and `make generate-check` for generated-code\n  changes, and `make ci-lint` for PR-relevant lint validation, or the reason\n  they were skipped is documented.\n- `make generate` was run when config structs or components changed, and the\n  regenerated files are committed.\n- Relevant unit tests and `make fmt-check` / `make lint` were run, or the reason\n  they were not run is documented.\n- New commands are registered in `commands.go`; deprecations have fixers.\n- SPDX/copyright headers are present on new source files.\n- Final handoff states what changed, what was validated, and any remaining risk or\n  follow-up."},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\n## Purpose\n\nPacker is HashiCorp's open-source (BUSL-1.1) CLI for building automated machine\nimages. It is a Go program that orchestrates pluggable **builders**,\n**provisioners**, **post-processors**, and **data sources** through the\n`hashicorp/packer-plugin-sdk`, driven by HCL2 templates (legacy JSON templates are\nstill supported). There is no database, no gRPC/gateway service, and no protobuf\nAPI surface in this repository.\n\nUse this file as the repo-specific operating contract. Prefer the existing `make`\ntargets and established patterns over invented workflows.\n\n## Default Working Mode\n\n- Keep chat concise. Share decision-worthy context, short progress updates, and\n  summarized command output; do not paste large logs or diffs unless asked.\n- Lead with the answer or outcome. Skip motivational filler and obvious recaps.\n- Start broad, unclear, or \"review/investigate/audit\" tasks with read-only\n  discovery and report findings before editing.\n- Ask for confirmation before non-trivial implementation when there are multiple\n  viable approaches, the request is ambiguous, or the change touches the plugin\n  SDK boundary, HCL2 template parsing, the command surface, CI/release workflows,\n  or security-relevant behavior.\n- Proceed without another confirmation when the user explicitly asks to implement,\n  fix, add, remove, regenerate, or run an approved command, or for trivial typo,\n  formatting, or docs cleanup.\n- When blocked by missing credentials, cloud access, or unclear intent, stop and\n  ask. Do not improvise around those blockers.\n\n## Scope And Boundaries\n\n- Work only inside this repository unless the user explicitly requests cross-repo\n  changes (e.g., the plugin SDK or a specific plugin repo).\n- Do not read from, write to, or execute files outside the workspace, including\n  `/tmp`, `~`, or `/etc`. Create temporary artifacts inside the repository only.\n- Treat files marked `// Code generated ... DO NOT EDIT` as derived output. Change\n  the source struct/`//go:generate` directive and regenerate; never hand-edit the\n  generated file. This includes `*.hcl2spec.go` and `*_enumer.go`.\n- Do not hand-edit vendored content, `go.sum`, or other generated artifacts unless\n  the task is explicitly about that output.\n- Do not access production systems, cloud consoles, Vault, 1Password, or cloud\n  accounts unless explicitly asked and safely configured. Acceptance tests boot\n  real infrastructure and may cost money — never run them without explicit intent.\n- Do not inspect, print, copy, or persist secrets from shell history, env vars,\n  `.envrc`, CI configuration, or credential stores.\n- Do not run destructive git or remote-system actions without explicit approval.\n\n## Approved Commands\n\nRun `make help` to list targets. Common ones:\n\n### Build\n\n- `make dev` builds and installs a development binary to `bin/packer` (requires a\n  prerelease tag in `version/version.go`).\n- `go build -o bin/packer .` is the minimal build if `make` is unavailable.\n\n### Generate\n\n- `make generate` runs `go generate ./...` to rebuild dynamically generated code\n  (HCL2 specs via `packer-sdc mapstructure-to-hcl2`, enumer output, fixer\n  deprecations). Run this after changing any config struct or adding a component.\n- `make generate-check` verifies generated code is up to date (fails on drift).\n\n### Format & Lint\n\n- `make fmt` runs `go fmt ./...`; `make fmt-check` fails if code is not formatted.\n- `make lint` runs `golangci-lint` over the repo (config in `.golangci.yml`). Use\n  `PKG_NAME=<dir> make lint` to scope. `make ci-lint` lints only newly changed\n  files against `origin/main`.\n\n### Test\n\n- `make test` runs unit tests (`go vet` + `go test`, 3m timeout). Prefer\n  `TEST=./path/... make test` or `TESTARGS=\"-run TestName\" make test` to scope.\n- `make testrace` runs unit tests with the race detector.\n- `make testacc` runs acceptance tests with `PACKER_ACC=1`. **These are slow, boot\n  real machines/cloud resources, and can cost money.** Only run when the user\n  explicitly asks and prerequisites are configured.\n\n## Architecture Rules\n\n- Components are plugins behind SDK interfaces. New behavior belongs in the right\n  component type: **builders** create machines/artifacts, **provisioners** run\n  against a machine via a **communicator** (SSH/WinRM/Docker), **post-processors**\n  transform/act on artifacts, **data sources** fetch inputs. Prefer post-processors\n  and provisioners for cross-builder (\"plugin-independent\") features, since they\n  operate on the SDK's `Artifact`/`Communicator` abstractions rather than a\n  specific builder.\n- Component config is defined by a Go struct plus a generated `*.hcl2spec.go`.\n  After editing config fields, run `make generate` and commit the regenerated file.\n- Keep changes backward compatible for existing templates. New fields must be\n  optional with sensible defaults; do not change the meaning of existing fields.\n- HCL2 parsing lives in `hcl2template/`; the CLI commands live in `command/`;\n  template fixers live in `fix/`. When adding a command, register it in\n  `commands.go`. When deprecating/renaming config, add a fixer.\n- Pass `context.Context` through build/orchestration and network-facing paths.\n- Use the SDK's existing helpers and error patterns instead of ad hoc equivalents.\n\n## Go Style\n\n- Follow standard Go formatting and the repository linter (`.golangci.yml`).\n- Every Go/HCL source file carries the copyright + `SPDX-License-Identifier:\n  BUSL-1.1` header (managed by `copywrite`, config in `.copywrite.hcl`). New files\n  must include it.\n- Keep packages lowercase and concise; export names only when they must cross a\n  package boundary.\n- Use domain terms already present in the repo: `builder`, `provisioner`,\n  `post-processor`, `datasource`, `communicator`, `artifact`, `template`,\n  `plugin`, `fixer`, `hcl2template`.\n- Return wrapped errors with useful context and preserve the original error.\n- Match surrounding struct layout, constructors, and table-driven test style.\n\n## Testing And Validation\n\n- Run the narrowest test set that proves the change, then broaden when the blast\n  radius justifies it (`TEST=./command/... make test`, then `make test`).\n- For PR-bound changes, run the applicable repo maintenance targets before\n  handoff: `make fmt` for Go edits, `make generate` plus `make generate-check`\n  when source changes affect generated files, and `make ci-lint` when the\n  change should satisfy the same lint expectations as CI. If one of these is\n  skipped, state why.\n- Add or update unit tests for behavior changes. If a bug fix is not covered,\n  explain why in the handoff.\n- After changing config structs or adding components, run `make generate` and\n  `make generate-check` so generated code stays in sync.\n- Do not leave formatting or generated-file drift for the user to discover at\n  push or review time; run the relevant `make` target and include the resulting\n  updates in the same change.\n- Do not run acceptance tests (`PACKER_ACC=1`) casually — they are slow and may\n  provision billable resources. State when validation was skipped and why.\n\n## Review Guidelines\n\nPrioritize findings over summary; do not edit unless asked.\n\n- Check correctness first: behavior, edge cases, regressions, nil handling,\n  context handling, and backward compatibility for existing templates.\n- Check that config changes are additive and that defaults preserve prior behavior.\n- Check that generated code (`*.hcl2spec.go`, enumer output) was regenerated when\n  its source changed — flag generated-code drift.\n- Check new commands are registered in `commands.go` and deprecations have fixers.\n- Check tests cover the changed behavior, not just compilation.\n- Flag risky changes to CI, release (`.release/`), CODEOWNERS, or security scanning\n  unless they are the explicit task.\n\n## Commit And PR Guidelines\n\n- Do not commit, branch, push, or open PRs unless explicitly requested.\n- Keep commits focused and logically atomic; use short imperative subjects.\n- Separate regenerated output from behavioral changes where it can be done cleanly.\n- Follow `.github/PULL_REQUEST_TEMPLATE.md`. PR text should say what changed and\n  why, and note any backward-compatibility impact on existing templates.\n- Add a changelog note (`CHANGELOG.md`) for user-facing changes.\n- Never include secrets, tokens, or credentials in commits, PR text, or logs.\n\n## Completion Checklist\n\nBefore finishing a task, verify the following when applicable.\n\n- Source-of-truth files were changed instead of generated output.\n- Applicable repo maintenance commands were run before handoff: `make fmt` for\n  Go edits, `make generate` and `make generate-check` for generated-code\n  changes, and `make ci-lint` for PR-relevant lint validation, or the reason\n  they were skipped is documented.\n- `make generate` was run when config structs or components changed, and the\n  regenerated files are committed.\n- Relevant unit tests and `make fmt-check` / `make lint` were run, or the reason\n  they were not run is documented.\n- New commands are registered in `commands.go`; deprecations have fixers.\n- SPDX/copyright headers are present on new source files.\n- Final handoff states what changed, what was validated, and any remaining risk or\n  follow-up.","category":"root","tokens":2309}]}