chore: migrate goreleaser to v2 APIs and add release documentation#122
Merged
michaelmcnees merged 3 commits intomainfrom Apr 6, 2026
Merged
Conversation
- Migrate archives.format (scalar) to formats (list) per goreleaser v2 deprecation - Migrate dockers + docker_manifests to dockers_v2; update Dockerfile.goreleaser to use $TARGETPLATFORM for multi-arch build context - Add order fields to changelog groups (Features=0, Bug Fixes=1) - Bundle LICENSE in release archives to satisfy BUSL-1.1 notice requirement - Add RELEASING.md with full release process documentation - Add docs/superpowers/specs/ files to version control Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds a new release process guide, multiple design/spec documents covering CI, config, scaffold, workflows, DB/migrations, connectors, AI/tooling, multi-node distribution, data transforms, and packaging updates for engine goreleaser/Dockerfile. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (1)
docs/superpowers/specs/2026-03-19-ai-tool-use-parallel-execution-design.md (1)
261-264: Consider varying sentence structure to improve readability.Three consecutive validation rules begin with "Tool". While this is clear and correct, varying the sentence structure can enhance readability.
✍️ Suggested alternative phrasing
- Tool `name` is unique within a step's tool list. -- Tool `action` references a valid connector. -- Tool params are valid for that connector (same validation as regular steps). +- Each tool's `action` references a valid connector. +- Parameters for each tool are valid for that connector (same validation as regular steps).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/superpowers/specs/2026-03-19-ai-tool-use-parallel-execution-design.md` around lines 261 - 264, The three validation bullets starting with "Tool" should be rephrased to vary sentence structure and improve flow: change "Tool `name` is unique within a step's tool list." to "Ensure each tool's `name` is unique within a step's tool list.", change "Tool `action` references a valid connector." to "Each tool's `action` must reference a valid connector.", change "Tool params are valid for that connector (same validation as regular steps)." to "Validate a tool's params against the corresponding connector's parameter schema (same validation as regular steps).", and keep "`max_tool_rounds` is within bounds." as "Ensure `max_tool_rounds` falls within the allowed bounds." Use the symbols `name`, `action`, tool params, and `max_tool_rounds` to locate and update the three bullets.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/superpowers/specs/2026-03-18-config-system-design.md`:
- Around line 19-25: The fenced code block in the markdown (the
package-structure snippet) is missing a language identifier; update the opening
triple-backtick for that block to include a language such as "text" (e.g.,
change ``` to ```text) so markdownlint rule MD040 is satisfied; locate the block
around the package layout in the
docs/superpowers/specs/2026-03-18-config-system-design.md file and add the
identifier to the existing fenced block.
In `@docs/superpowers/specs/2026-03-18-docker-compose-design.md`:
- Around line 47-53: The markdown fences around the Postgres DSN examples are
unlabeled and trigger MD040; add a language hint (e.g., use "text") to both
fenced code blocks that contain
"postgres://localhost:5432/mantle?sslmode=disable" and
"postgres://mantle:mantle@localhost:5432/mantle?sslmode=disable" so the blocks
become ```text ... ``` to satisfy markdownlint; ensure both occurrences are
updated consistently.
In `@docs/superpowers/specs/2026-03-18-go-project-scaffold-design.md`:
- Around line 18-45: The three unlabeled fenced code blocks (the directory
listing block and the two version-output blocks) are triggering MD040; update
each opening triple-backtick to include a language label (e.g., change ``` to
```text) so the blocks become labeled (directory listing, default version
output, and ldflags version output). Ensure you only modify the three fences
surrounding the block starting with "cmd/mantle/" and the two blocks showing
"mantle dev ..." and "mantle v0.1.0 ..." so markdownlint no longer flags MD040.
In `@docs/superpowers/specs/2026-03-18-workflow-validation-design.md`:
- Line 24: The spec currently documents two different validator signatures —
Validate(*Workflow) at line 24 and Validate(result *ParseResult) at line 97 —
causing inconsistency; pick one canonical signature and update all mentions so
they match (e.g., change the heading/entry at line 24 or the definition at line
97) so the same symbol Validate and its single parameter type (either *Workflow
or *ParseResult) is used throughout the document and in the referenced
validate.go note; ensure any surrounding text that describes the parameter name
(result vs workflow) is updated to match the chosen signature.
In `@docs/superpowers/specs/2026-03-19-multi-node-distribution-design.md`:
- Line 196: The spec uses inconsistent table names: change the singular
identifier `workflow_execution` to the plural `workflow_executions` in the
sentence "If retries are exhausted, marks the `workflow_execution` as
`failed`..." so the doc consistently refers to `workflow_executions` (search for
`workflow_execution` occurrences and replace them with `workflow_executions`,
e.g., in the sentence mentioning marking as `failed` and cancelling pending
steps).
In `@docs/superpowers/specs/2026-03-27-workflow-composition-design.md`:
- Around line 59-64: The spec suggests adding a duplicate field MaxWorkflowDepth
to EngineConfig; instead, remove the add-field instruction and update the
document to describe setting the default and env binding for the existing
EngineConfig.MaxWorkflowDepth: state that the configuration loader should call
v.SetDefault("engine.max_workflow_depth", 10) and
v.BindEnv("engine.max_workflow_depth", "MANTLE_ENGINE_MAX_WORKFLOW_DEPTH") to
provide a default and environment override for the existing MaxWorkflowDepth
field on EngineConfig rather than re-defining the struct field.
In `@packages/engine/.goreleaser.yaml`:
- Around line 50-63: Add the QEMU setup action into the release workflow by
inserting a step that uses docker/setup-qemu-action@v3 immediately before the
docker/setup-buildx-action@v3 step in .github/workflows/release-engine.yml;
ensure the new step mirrors the existing action steps (name, uses:
docker/setup-qemu-action@v3) so QEMU is initialized prior to buildx for
multi-platform builds that rely on $TARGETPLATFORM in Dockerfile.goreleaser.
In `@RELEASING.md`:
- Around line 139-156: The prose inconsistently uses “pre-release” and
“prerelease”; standardize all prose occurrences to “pre-release” while keeping
the config key backtick-quoted as `prerelease: auto` (do not change the config
key). Update the header, descriptive sentences, and any inline text (e.g., the
paragraph that explains goreleaser's behavior and the sentence “goreleaser's
`prerelease: auto` publishes...”) so every non-code mention reads “pre-release”,
and ensure the code/config examples remain exactly as-is.
- Line 31: Replace the placeholder link text "[the relevant issue]" in
RELEASING.md with the actual issue URL referencing the tracked rename of the
workflow (the one noting release-please.yml → changeset-version.yml); locate the
sentence mentioning "release-please.yml" and update the bracketed reference to
point to the concrete issue link (e.g.,
https://github.com/your-repo/your-project/issues/NNN) so readers can follow the
tracked rename.
---
Nitpick comments:
In `@docs/superpowers/specs/2026-03-19-ai-tool-use-parallel-execution-design.md`:
- Around line 261-264: The three validation bullets starting with "Tool" should
be rephrased to vary sentence structure and improve flow: change "Tool `name` is
unique within a step's tool list." to "Ensure each tool's `name` is unique
within a step's tool list.", change "Tool `action` references a valid
connector." to "Each tool's `action` must reference a valid connector.", change
"Tool params are valid for that connector (same validation as regular steps)."
to "Validate a tool's params against the corresponding connector's parameter
schema (same validation as regular steps).", and keep "`max_tool_rounds` is
within bounds." as "Ensure `max_tool_rounds` falls within the allowed bounds."
Use the symbols `name`, `action`, tool params, and `max_tool_rounds` to locate
and update the three bullets.
🪄 Autofix (Beta)
❌ Autofix failed (check again to retry)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 3ba41f4b-adb6-4b23-b7cf-8447c2922301
📒 Files selected for processing (18)
RELEASING.mddocs/superpowers/specs/2026-03-18-ci-pipeline-design.mddocs/superpowers/specs/2026-03-18-config-system-design.mddocs/superpowers/specs/2026-03-18-docker-compose-design.mddocs/superpowers/specs/2026-03-18-go-project-scaffold-design.mddocs/superpowers/specs/2026-03-18-health-endpoints-design.mddocs/superpowers/specs/2026-03-18-migrations-design.mddocs/superpowers/specs/2026-03-18-workflow-apply-design.mddocs/superpowers/specs/2026-03-18-workflow-validation-design.mddocs/superpowers/specs/2026-03-19-ai-tool-use-parallel-execution-design.mddocs/superpowers/specs/2026-03-19-multi-node-distribution-design.mddocs/superpowers/specs/2026-03-24-data-transformation-design.mddocs/superpowers/specs/2026-03-25-docker-connector-artifacts-design.mddocs/superpowers/specs/2026-03-26-v040-safety-net-design.mddocs/superpowers/specs/2026-03-27-env-map-config-design.mddocs/superpowers/specs/2026-03-27-workflow-composition-design.mdpackages/engine/.goreleaser.yamlpackages/engine/Dockerfile.goreleaser
docs/superpowers/specs/2026-03-18-go-project-scaffold-design.md
Outdated
Show resolved
Hide resolved
| workflow/ | ||
| workflow.go # Workflow, Step, Input, RetryPolicy structs | ||
| parse.go # Parse(filename) — YAML parsing with yaml.Node line tracking | ||
| validate.go # Validate(*Workflow) — structural validation rules |
Contributor
There was a problem hiding this comment.
Align the validator signature in both sections.
Line 24 documents Validate(*Workflow), but Line 97 defines Validate(result *ParseResult). Please keep one signature throughout the spec.
Suggested doc fix
- validate.go # Validate(*Workflow) — structural validation rules
+ validate.go # Validate(*ParseResult) — structural validation rulesAlso applies to: 97-97
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/superpowers/specs/2026-03-18-workflow-validation-design.md` at line 24,
The spec currently documents two different validator signatures —
Validate(*Workflow) at line 24 and Validate(result *ParseResult) at line 97 —
causing inconsistency; pick one canonical signature and update all mentions so
they match (e.g., change the heading/entry at line 24 or the definition at line
97) so the same symbol Validate and its single parameter type (either *Workflow
or *ParseResult) is used throughout the document and in the referenced
validate.go note; ensure any surrounding text that describes the parameter name
(result vs workflow) is updated to match the chosen signature.
docs/superpowers/specs/2026-03-19-multi-node-distribution-design.md
Outdated
Show resolved
Hide resolved
docs/superpowers/specs/2026-03-27-workflow-composition-design.md
Outdated
Show resolved
Hide resolved
Comment on lines
+50
to
63
| dockers_v2: | ||
| - ids: [mantle] | ||
| dockerfile: Dockerfile.goreleaser | ||
| build_flag_templates: | ||
| - "--platform=linux/amd64" | ||
| - image_templates: | ||
| - "ghcr.io/dvflw/mantle:{{ .Version }}-arm64" | ||
| use: buildx | ||
| ids: [mantle] | ||
| goos: linux | ||
| goarch: arm64 | ||
| dockerfile: Dockerfile.goreleaser | ||
| build_flag_templates: | ||
| - "--platform=linux/arm64" | ||
|
|
||
| docker_manifests: | ||
| - name_template: "ghcr.io/dvflw/mantle:{{ .Version }}" | ||
| image_templates: | ||
| - "ghcr.io/dvflw/mantle:{{ .Version }}-amd64" | ||
| - "ghcr.io/dvflw/mantle:{{ .Version }}-arm64" | ||
| - name_template: "ghcr.io/dvflw/mantle:{{ .Major }}.{{ .Minor }}" | ||
| image_templates: | ||
| - "ghcr.io/dvflw/mantle:{{ .Version }}-amd64" | ||
| - "ghcr.io/dvflw/mantle:{{ .Version }}-arm64" | ||
| skip_push: auto | ||
| - name_template: "ghcr.io/dvflw/mantle:{{ .Major }}" | ||
| image_templates: | ||
| - "ghcr.io/dvflw/mantle:{{ .Version }}-amd64" | ||
| - "ghcr.io/dvflw/mantle:{{ .Version }}-arm64" | ||
| skip_push: auto | ||
| - name_template: "ghcr.io/dvflw/mantle:latest" | ||
| image_templates: | ||
| - "ghcr.io/dvflw/mantle:{{ .Version }}-amd64" | ||
| - "ghcr.io/dvflw/mantle:{{ .Version }}-arm64" | ||
| skip_push: auto | ||
| images: | ||
| - "ghcr.io/dvflw/mantle" | ||
| tags: | ||
| - "{{ .Version }}" | ||
| # Floating tags (major.minor, major, latest) are only pushed for stable | ||
| # releases. Empty template results are skipped by goreleaser, so these | ||
| # evaluate to "" and are dropped for any pre-release version. | ||
| - "{{ if not .Prerelease }}{{ .Major }}.{{ .Minor }}{{ end }}" | ||
| - "{{ if not .Prerelease }}{{ .Major }}{{ end }}" | ||
| - "{{ if not .Prerelease }}latest{{ end }}" | ||
|
|
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== release workflow setup steps =="
rg -n -C2 'setup-qemu-action|setup-buildx-action|goreleaser-action|docker/login-action' .github/workflows/release-engine.yml
echo
echo "== goreleaser docker v2 config =="
rg -n -C2 'dockers_v2|ids:|images:|tags:' packages/engine/.goreleaser.yaml
echo
echo "== Dockerfile multi-platform binary path =="
rg -n -C2 'ARG TARGETPLATFORM|COPY \\$TARGETPLATFORM/mantle' packages/engine/Dockerfile.goreleaserRepository: dvflw/mantle
Length of output: 989
Add docker/setup-qemu-action before Buildx in the release workflow.
The release workflow is missing QEMU initialization for multi-platform Docker builds. With dockers_v2 configured for multi-platform images and Dockerfile.goreleaser expecting platform-specific binaries via $TARGETPLATFORM, ARM64 RUN layers will fail without QEMU. Add docker/setup-qemu-action@v3 immediately before docker/setup-buildx-action@v3 in .github/workflows/release-engine.yml (around line 32).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/engine/.goreleaser.yaml` around lines 50 - 63, Add the QEMU setup
action into the release workflow by inserting a step that uses
docker/setup-qemu-action@v3 immediately before the docker/setup-buildx-action@v3
step in .github/workflows/release-engine.yml; ensure the new step mirrors the
existing action steps (name, uses: docker/setup-qemu-action@v3) so QEMU is
initialized prior to buildx for multi-platform builds that rely on
$TARGETPLATFORM in Dockerfile.goreleaser.
| 5b. release-helm.yml → helm push OCI + GitHub Release | ||
| ``` | ||
|
|
||
| > **Note on workflow naming:** `release-please.yml` is named after a tool we evaluated but didn't adopt — it actually runs the Changesets CLI. A rename to `changeset-version.yml` is tracked in [the relevant issue]. |
Contributor
There was a problem hiding this comment.
Replace placeholder link text with an actual URL.
Line 31 references [the relevant issue] but does not point to a concrete issue link, so readers cannot follow up.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@RELEASING.md` at line 31, Replace the placeholder link text "[the relevant
issue]" in RELEASING.md with the actual issue URL referencing the tracked rename
of the workflow (the one noting release-please.yml → changeset-version.yml);
locate the sentence mentioning "release-please.yml" and update the bracketed
reference to point to the concrete issue link (e.g.,
https://github.com/your-repo/your-project/issues/NNN) so readers can follow the
tracked rename.
Comment on lines
+139
to
+156
| ## Pre-releases | ||
|
|
||
| To cut a pre-release (e.g. `0.5.0-rc.1`), no changeset is needed — bump the version manually and tag directly: | ||
|
|
||
| ```bash | ||
| # 1. Set the pre-release version in package.json | ||
| # Edit packages/engine/package.json: "version": "0.5.0-rc.1" | ||
| git add packages/engine/package.json | ||
| git commit -m "chore: bump engine to 0.5.0-rc.1" | ||
| git push origin main | ||
|
|
||
| # 2. Tag and push | ||
| git tag engine/v0.5.0-rc.1 | ||
| git push origin engine/v0.5.0-rc.1 | ||
| ``` | ||
|
|
||
| goreleaser's `prerelease: auto` publishes the GitHub Release as a pre-release when the version contains a pre-release identifier. The versioned Docker image (`0.5.0-rc.1`) is pushed; floating tags (`latest`, `major`, `major.minor`) are not. | ||
|
|
Contributor
There was a problem hiding this comment.
Standardize “pre-release” wording in prose.
The document mixes “pre-release” and “prerelease.” Keep prerelease: auto as-is (config key), but use one prose variant consistently for readability.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~155-~155: Do not mix variants of the same word (‘prerelease’ and ‘pre-release’) within a single text.
Context: ...in engine/v0.5.0-rc.1 ``` goreleaser's prerelease: auto publishes the GitHub Release as ...
(EN_WORD_COHERENCY)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@RELEASING.md` around lines 139 - 156, The prose inconsistently uses
“pre-release” and “prerelease”; standardize all prose occurrences to
“pre-release” while keeping the config key backtick-quoted as `prerelease: auto`
(do not change the config key). Update the header, descriptive sentences, and
any inline text (e.g., the paragraph that explains goreleaser's behavior and the
sentence “goreleaser's `prerelease: auto` publishes...”) so every non-code
mention reads “pre-release”, and ensure the code/config examples remain exactly
as-is.
Contributor
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. An unexpected error occurred while generating fixes: Resource not accessible by integration - https://docs.github.com/rest/git/trees#create-a-tree |
Collaborator
Author
@claude address these items, please |
|
Claude finished @michaelmcnees's task in 2m 20s —— View job Addressing CodeRabbit Review CommentsTasks
Not addressed
|
- Add language identifiers to unlabeled fenced code blocks (MD040) in config-system, docker-compose, and go-project-scaffold specs - Align Validate() signature to Validate(*ParseResult) throughout workflow-validation-design.md - Fix singular/plural table name: workflow_execution → workflow_executions in multi-node-distribution-design.md - Reword EngineConfig field to avoid implying a duplicate struct field in workflow-composition-design.md - Vary sentence structure in ai-tool-use validation rule bullets Co-authored-by: Michael McNees <michaelmcnees@users.noreply.github.com>
Contributor
|
@coderabbitai review |
Contributor
✅ Actions performedReview triggered.
|
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/superpowers/specs/2026-03-19-ai-tool-use-parallel-execution-design.md`:
- Line 151: Three fenced code blocks are missing language identifiers (MD040)
causing lint/render issues; update the three unlabeled fences by adding explicit
languages: mark the first block (step_executions YAML-like snippet containing
keys like step_executions, id, execution_id) with "text" or "yaml", mark the
pseudocode block that defines conversation handling and child step
creation/lookup (contains variables conversation, cached_llm_responses,
tool_calls, child_row) with "python" or "text", and mark the execution tree
block (starts with "EXECUTION abc123" and multiline status lines) with "text";
ensure each opening triple-backtick includes the chosen language identifier to
satisfy MD040.
- Around line 69-72: The spec statement claiming "No `continue_on_failure`
option in V1.1" contradicts the orchestrator's existing behavior for steps
tagged `continue_on_error=true`; reconcile by updating the spec text and
terminology: explicitly reference the existing `continue_on_error` flag used by
the orchestrator (and note there is no separate `continue_on_failure` setting),
describe that steps with `continue_on_error=true` are considered resolved for
downstream scheduling even when they fail, and clarify that V1.1's cascading
failure model only applies to steps without `continue_on_error=true`; update the
paragraph mentioning V1.1 and the cascading model and add a short note naming
the orchestrator behavior (`continue_on_error`) so implementers know which flag
controls downstream scheduling.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ff4af8b9-6c8e-45f9-9538-618b7ba5b107
📒 Files selected for processing (7)
docs/superpowers/specs/2026-03-18-config-system-design.mddocs/superpowers/specs/2026-03-18-docker-compose-design.mddocs/superpowers/specs/2026-03-18-go-project-scaffold-design.mddocs/superpowers/specs/2026-03-18-workflow-validation-design.mddocs/superpowers/specs/2026-03-19-ai-tool-use-parallel-execution-design.mddocs/superpowers/specs/2026-03-19-multi-node-distribution-design.mddocs/superpowers/specs/2026-03-27-workflow-composition-design.md
✅ Files skipped from review due to trivial changes (4)
- docs/superpowers/specs/2026-03-18-docker-compose-design.md
- docs/superpowers/specs/2026-03-18-go-project-scaffold-design.md
- docs/superpowers/specs/2026-03-18-config-system-design.md
- docs/superpowers/specs/2026-03-18-workflow-validation-design.md
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/superpowers/specs/2026-03-27-workflow-composition-design.md
docs/superpowers/specs/2026-03-19-ai-tool-use-parallel-execution-design.md
Show resolved
Hide resolved
docs/superpowers/specs/2026-03-19-ai-tool-use-parallel-execution-design.md
Outdated
Show resolved
Hide resolved
Collaborator
Author
|
Verify each finding against the current code and only fix it if needed. Inline comments:
|
|
Claude finished @michaelmcnees's task in 1m 8s —— View job Addressing CodeRabbit Review CommentsTasks
|
…uracy - Add `text` language identifier to three unlabeled fenced code blocks - Replace inaccurate `continue_on_failure` note with accurate `continue_on_error` description Co-authored-by: Michael McNees <michaelmcnees@users.noreply.github.com>
Contributor
|
@coderabbitai review |
Contributor
✅ Actions performedReview triggered.
|
7 tasks
michaelmcnees
pushed a commit
that referenced
this pull request
Apr 7, 2026
- release-engine.yml: add docker/setup-qemu-action@v3 before Buildx to support multi-platform (ARM64) Docker builds; without QEMU, ARM64 RUN layers fail in buildx emulation - RELEASING.md: replace [the relevant issue] placeholder with actual link to #123 (rename release-please.yml to changeset-version.yml) https://claude.ai/code/session_01CuTGMFzUAdw5L5p5n9vEa5
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
archives.format(scalar) →formats(list)dockers+docker_manifests→dockers_v2; updatesDockerfile.goreleaserto use$TARGETPLATFORMfor multi-arch build contextorder: 0/1tochangelog.groups(was missing on Features and Bug Fixes entries)filesstanza to.goreleaser.yamlso every release tarball includesLICENSE, satisfying BUSL-1.1's notice requirementRELEASING.md— new contributor-facing release process guide covering: prerequisites, the full changeset → Version PR → tag → artifact flow, partial-failure recovery, pre-release instructions, and rollback stepsdocs/superpowers/specs/— adds historical spec files to version control (specs are tracked; plans remain gitignored)Behavioral changes to call out
ghcr.io/dvflw/mantle:<version>-amd64and-arm64as intermediary tags.dockers_v2only pushes the final multi-arch manifest tags (e.g.ghcr.io/dvflw/mantle:0.4.0). Update any CI or deploy configs referencing the suffixed form.latest,major,major.minorare still only pushed for stable releases (pre-release versions get the versioned tag only).Out of scope — tracked as follow-up issues
release-please.yml→changeset-version.ymlalpine:3.21inDockerfile.goreleaserto a digestgo-licensesNOTICE generation step to the release pipelineTest plan
engine/v*tag pushLICENSEfile-amd64/-arm64tags in production)RELEASING.mdfor accuracy against the live pipeline🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation
Chores