chore: back-merge main into next (conflicts)#373
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.
Remove the stale release-as pin
This back-merge already records plugins/aidd-ui at 0.1.0-alpha.0 in the manifest and ships an aidd-ui changelog, but leaving release-as set keeps forcing that same version on later release-please runs instead of resuming automatic bumps; the new release docs in docs/RELEASE.md:49-51 call out that this pin must be removed after the forced cut. The next real change under plugins/aidd-ui can therefore try to reuse the already-released aidd-ui-v0.1.0-alpha.0 version/tag rather than producing the next alpha.
Useful? React with 👍 / 👎.
| @@ -82,6 +82,17 @@ | |||
| "jsonpath": "$.version" | |||
| } | |||
| ] | |||
| }, | |||
| "plugins/aidd-ui": { | |||
There was a problem hiding this comment.
Add aidd-ui to the plugin artifact matrix
Registering plugins/aidd-ui here makes release-please create an aidd-ui package release when that path is released, but the build-plugin matrix I checked in .github/workflows/ci.yml:184 still enumerates only the six older plugins. In that release scenario, CI creates the GitHub release but never runs the zip/upload steps for aidd-ui, so users do not get the documented <plugin>-vX.Y.Z.zip artifact for this new plugin.
Useful? React with 👍 / 👎.
|
|
||
| - None. | ||
| - Delegate every step; never write or judge code yourself. | ||
| - Mode: default `interactive`, pausing for approval at each step; switch to `auto` only when the caller says so, then decide alone and never ask. |
There was a problem hiding this comment.
Keep async SDLC runs unattended
Making SDLC interactive by default breaks the async-dev CI path: I checked plugins/aidd-orchestrator/skills/00-async-dev/actions/run/05-delegate-sdlc.md:35-38, and it invokes the discovered SDLC skill with only the issue text while explicitly avoiding orchestrator-specific instructions, so it never says auto. In that headless workflow context, the SDLC will pause for approvals at each step instead of creating a PR, and the post-job will mark the issue blocked.
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 back-merge failure label
This failure handler asks gh issue create to add back-merge-failed, but I checked .github/labels.yml and that label is not defined. The GitHub CLI --label flag adds existing labels by name, and missing labels cause issue creation to fail; because the command is followed by || echo, a rejected back-merge can end with only a log line instead of the tracking issue this step is meant to guarantee.
Useful? React with 👍 / 👎.
| ## Process | ||
|
|
||
| 1. **Read.** Look at the diff and group it by concern. | ||
| 2. **Pick.** Stage the files for one concern. With explicit paths, stage exactly those; otherwise keep what is already staged, never adding unstaged files on your own. |
There was a problem hiding this comment.
Stage unstaged changes before committing
For the common commit my changes case where the user has only unstaged edits and passes no explicit paths, this instruction keeps the staged set as-is and explicitly forbids adding the unstaged files. The following message/commit actions operate on the staged diff, so the skill either fails with nothing to commit or ignores the user's edits despite the skill being advertised for committing current changes.
Useful? React with 👍 / 👎.
| @../assets/CONTRIBUTING.md | ||
| ``` | ||
|
|
||
| 5. **Bootstrap.** Commit once so `HEAD` exists and is pushable: `git -C <cwd> commit --allow-empty -m "chore: initialize repository"`. |
There was a problem hiding this comment.
Commit the generated CONTRIBUTING file
On a fresh repo, the previous step writes CONTRIBUTING.md, but this bootstrap commit never stages it before running git commit --allow-empty. The result is an empty initial commit with the generated template left untracked, so a subsequent publish pushes a repository without the contribution guide the init action just created.
Useful? React with 👍 / 👎.
| - Prior report present: `01-detect` then `03-diff` then `02-render-report` | ||
|
|
||
| The `02-render-report` action always runs last and writes `<source>-shadow-report.md` next to the source. | ||
| Dispatch by context: with no prior report run `detect` then `render-report`; with one, run `detect` then `diff`. |
There was a problem hiding this comment.
Render the updated shadow report after diffing
When a prior shadow report exists, this dispatch path now runs only detect then diff, but 03-diff only classifies gaps and hands its sets to 02-render-report; the render action is the step that actually writes <source>-shadow-report.md. Rerunning the skill on an existing report therefore computes the diff but leaves the report file and clean/stale status unchanged.
Useful? React with 👍 / 👎.
Automated back-merge hit conflicts (CHANGELOG / manifest / version files). Resolve manually, then merge into next.