@laitszkin/apollo-toolkit 3.3.2 → 3.3.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -7,6 +7,11 @@ All notable changes to this repository are documented in this file.
7
7
  ### Added
8
8
  - (None yet)
9
9
 
10
+ ## [v3.3.3] - 2026-04-27
11
+
12
+ ### Changed
13
+ - Require `review-change-set` after merge verification before `merge-changes-from-local-branches` can continue into archival or submission.
14
+
10
15
  ## [v3.3.2] - 2026-04-27
11
16
 
12
17
  ### Changed
@@ -4,20 +4,22 @@ description: >-
4
4
  Read changes from local branches identified by branch name and merge them back
5
5
  into the current local branch. When conflicts arise, auto-resolve them by
6
6
  keeping correct functionality (preferring the more recent change on the same
7
- line, or the change that preserves working behavior). Run `archive-specs`
8
- after merge verification so completed plan sets are archived and durable
9
- project docs are synchronized, then hand the current branch state to
10
- `commit-and-push` so the final submit workflow commits and pushes on that same
11
- local branch. Use when the user asks to consolidate local branch work, merge
12
- named branches into the current branch, or prepare the current branch for
13
- integration.
7
+ line, or the change that preserves working behavior). After merge verification,
8
+ require `review-change-set` to review the merged code and confirm it still
9
+ matches the active spec documents before any submission workflow continues.
10
+ Run `archive-specs` only after that review gate passes so completed plan sets
11
+ are archived and durable project docs are synchronized, then hand the current
12
+ branch state to `commit-and-push` so the final submit workflow commits and
13
+ pushes on that same local branch. Use when the user asks to consolidate local
14
+ branch work, merge named branches into the current branch, or prepare the
15
+ current branch for integration.
14
16
  ---
15
17
 
16
18
  # Merge Changes from Local Branches
17
19
 
18
20
  ## Dependencies
19
21
 
20
- - Required: `archive-specs` to archive completed plan sets and synchronize durable project docs after merge verification, and `commit-and-push` for the final current-branch submission flow.
22
+ - Required: `review-change-set` to review the merged code and confirm spec alignment before submission, `archive-specs` to archive completed plan sets and synchronize durable project docs after the review gate passes, and `commit-and-push` for the final current-branch submission flow.
21
23
  - Conditional: none.
22
24
  - Optional: none.
23
25
  - Fallback: If git operations fail, stop and report the error.
@@ -25,7 +27,7 @@ description: >-
25
27
  ## Standards
26
28
 
27
29
  - Evidence: Inspect the original current branch, local branches, branch-name matches provided by the user or active spec names, actual conflicting files, and any active batch-spec `coordination.md` merge-order guidance before deciding what to merge.
28
- - Execution: Merge only the relevant named branches back into the original current branch, read any active batch-spec `coordination.md` and honor its documented merge order when present, resolve conflicts by reading both sides and editing the merged result to preserve shipped behavior, verify the merged state, delete each successfully merged source branch and its detached worktree only after the merged result is confirmed, run `archive-specs` so completed plan sets are archived and durable docs are synchronized, then hand the final current-branch state to `commit-and-push` so changelog/readiness/commit/push work happens through the shared submission workflow on the same branch.
30
+ - Execution: Merge only the relevant named branches back into the original current branch, read any active batch-spec `coordination.md` and honor its documented merge order when present, resolve conflicts by reading both sides and editing the merged result to preserve shipped behavior, verify the merged state, run `review-change-set` to confirm the merged code still matches the active spec documents, delete each successfully merged source branch and its detached worktree only after the merged result is confirmed, run `archive-specs` only after the review gate passes so completed plan sets are archived and durable docs are synchronized, then hand the final current-branch state to `commit-and-push` so changelog/readiness/commit/push work happens through the shared submission workflow on the same branch.
29
31
  - Quality: Never use blanket timestamp rules or default `-X ours/theirs` conflict resolution as the primary merge strategy, never infer in-scope branches from ancestry heuristics when branch names already define the target set, and do not declare success until the final current-branch state has been checked, verified, and cleared for post-merge archival/doc-sync work.
30
32
  - Output: Produce a clean current branch with all relevant named-branch changes integrated and ready for the shared submit workflow.
31
33
 
@@ -116,9 +118,16 @@ For each in-scope named branch:
116
118
  ```
117
119
  - If verification fails, fix the merged state on the current branch before proceeding.
118
120
 
121
+ ### 4.5) Review the merged change set before submission
122
+
123
+ - After merge verification passes, invoke `review-change-set` on the merged current branch.
124
+ - Compare the merged code against the active spec documents and any relevant `docs/plans/` artifacts that governed the merge.
125
+ - Do not proceed to archival or submission until the review returns no actionable findings and the merged state is confirmed to match the spec documents.
126
+ - If review finds a problem or spec mismatch, fix the current branch, rerun verification, and review again before continuing.
127
+
119
128
  ### 5) Archive completed specs and sync durable project docs
120
129
 
121
- - After all in-scope merges succeed and the current-branch state has been verified, invoke `archive-specs`.
130
+ - After all in-scope merges succeed, the current-branch state has been verified, and `review-change-set` has confirmed the merged code matches the spec documents, invoke `archive-specs`.
122
131
  - Let `archive-specs` convert and archive any completed `docs/plans/...` spec sets that now reflect the delivered outcome.
123
132
  - Let `archive-specs` synchronize durable project docs and `AGENTS.md` when the merged result changed operator workflows, repository guidance, or user-visible behavior.
124
133
  - Do not proceed to the final submission commit while required archival or documentation updates remain unfinished.
@@ -141,7 +150,7 @@ For each in-scope named branch:
141
150
  - the currently checked-out branch
142
151
  - branches that were skipped, failed to merge, or still need manual follow-up
143
152
  - If `git branch -d` refuses deletion because the branch is not actually merged, stop and report the branch instead of forcing deletion with `-D`.
144
- - Once merge verification plus archival/doc synchronization pass, invoke `commit-and-push` for the original current branch so the final submission flow owns:
153
+ - Once merge verification, `review-change-set`, and archival/doc synchronization pass, invoke `commit-and-push` for the original current branch so the final submission flow owns:
145
154
  - `CHANGELOG.md` readiness
146
155
  - the final commit creation on the original current branch
147
156
  - the user-requested push on that same branch
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@laitszkin/apollo-toolkit",
3
- "version": "3.3.2",
3
+ "version": "3.3.3",
4
4
  "description": "Apollo Toolkit npm installer for managed skill copying across Codex, OpenClaw, and Trae.",
5
5
  "license": "MIT",
6
6
  "author": "LaiTszKin",