chore: back-merge main into next (conflicts)#372
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 405d83fc38
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| "plugins/aidd-ui": { | ||
| "package-name": "aidd-ui", | ||
| "release-as": "0.1.0-alpha.0", |
There was a problem hiding this comment.
Include aidd-ui in plugin artifact builds
Now that aidd-ui is registered as a release-please package, an aidd-ui-only release will put plugins/aidd-ui in paths_released, but the build-plugin matrix in .github/workflows/ci.yml:183-184 still enumerates only the six older plugins. In that scenario every matrix row evaluates released=false, so the aidd-ui-v<version>.zip asset is never built or uploaded even though the release exists.
Useful? React with 👍 / 👎.
| }, | ||
| "plugins/aidd-ui": { | ||
| "package-name": "aidd-ui", | ||
| "release-as": "0.1.0-alpha.0", |
There was a problem hiding this comment.
Remove the stale aidd-ui release pin
This back-merge already contains the aidd-ui 0.1.0-alpha.0 changelog and manifest entry, but the config still pins future releases with release-as. The release docs added in this same change say to remove that pin after the release ships; leaving it here forces the next aidd-ui releasable change back to 0.1.0-alpha.0 instead of allowing the normal release-please bump.
Useful? React with 👍 / 👎.
| gh issue create \ | ||
| --repo "${{ github.repository }}" \ | ||
| --title "Back-merge main into next failed (run ${{ github.run_id }})" \ | ||
| --label "back-merge-failed" \ |
There was a problem hiding this comment.
Define the label before using it for failure issues
The GitHub CLI manual documents --label <name> as adding labels by name, and I checked .github/labels.yml: back-merge-failed is not defined there. When this failure path runs in a repo whose labels were synced from the canonical file, gh issue create fails while trying to apply the missing label, then the trailing || echo swallows the failure, so no tracking issue is opened.
Useful? React with 👍 / 👎.
| 2. **Push and open.** Invoke `pull-request` to push the branch and open the change request. Reference `plan_path` in the body. | ||
| 3. **Return** `commit_sha` and `change_request_url` to the SDLC orchestrator. | ||
| 1. **Gate.** Confirm `04` returned a `ship` verdict and HEAD is on a non-default branch. Without a `ship` verdict, or on `iterate`, stop and re-run `04` (looping to `03` on `iterate`). On the default branch, stop with `contract_violation: on_default_branch` and commit nothing. | ||
| 2. **Freshness.** Confirm no code landed after the reviewed SHA: `git diff --name-only <reviewed-sha> HEAD` must list only plan-tracking files. Any source change means the review is stale, so stop and re-run `04`. Never ship unreviewed code. |
There was a problem hiding this comment.
Check the dirty tree before shipping reviewed code
If any source file is edited after the checker captures the reviewed SHA but before ship runs, this freshness check only compares committed HEAD against the reviewed commit and ignores staged or unstaged worktree changes. The following commit capability can then include those dirty files, so unreviewed code can be committed and pushed despite the “Never ship unreviewed code” gate.
Useful? React with 👍 / 👎.
| 3. **Return** `commit_sha` and `change_request_url` to the SDLC orchestrator. | ||
| 1. **Gate.** Confirm `04` returned a `ship` verdict and HEAD is on a non-default branch. Without a `ship` verdict, or on `iterate`, stop and re-run `04` (looping to `03` on `iterate`). On the default branch, stop with `contract_violation: on_default_branch` and commit nothing. | ||
| 2. **Freshness.** Confirm no code landed after the reviewed SHA: `git diff --name-only <reviewed-sha> HEAD` must list only plan-tracking files. Any source change means the review is stale, so stop and re-run `04`. Never ship unreviewed code. | ||
| 3. **Commit.** Invoke a commit capability, discovered at runtime, with the plan's objective. It picks the message format; never dictate one here. |
There was a problem hiding this comment.
Skip the final commit when the branch is clean
02-implement now commits each phase and the final implemented status, and 04-review commits the reviewed plan status, so a normal SDLC run reaches 05-ship with a clean branch that already contains the reviewed changes. This unconditional commit step then invokes the commit capability with nothing left to stage, which can stop the end-to-end flow before opening the PR; when the branch is already clean, ship should use the existing reviewed HEAD as the commit SHA and proceed to the change request.
Useful? React with 👍 / 👎.
Automated back-merge hit conflicts (CHANGELOG / manifest / version files). Resolve manually, then merge into next.