@laitszkin/apollo-toolkit 2.14.0 → 2.14.1
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
|
@@ -4,6 +4,16 @@ All notable changes to this repository are documented in this file.
|
|
|
4
4
|
|
|
5
5
|
## [Unreleased]
|
|
6
6
|
|
|
7
|
+
## [v2.14.1] - 2026-04-06
|
|
8
|
+
|
|
9
|
+
### Changed
|
|
10
|
+
- Tighten `merge-changes-from-local-branches` so it inspects branch divergence before merging, resolves conflicts by composing verified behavior instead of relying on blanket `-X ours/theirs` or timestamp heuristics, and requires targeted verification after conflictful merges.
|
|
11
|
+
|
|
12
|
+
### Fixed
|
|
13
|
+
- Add missing `agents/openai.yaml` metadata for `merge-changes-from-local-branches` and `implement-specs-with-worktree` so repository agent-config validation passes and both skills expose UI metadata consistently.
|
|
14
|
+
|
|
15
|
+
## [v2.14.0] - 2026-04-05
|
|
16
|
+
|
|
7
17
|
### Added
|
|
8
18
|
- Add `agents` install mode to CLI and installer, aligning npm-based CLI with shell script capabilities.
|
|
9
19
|
- Add `implement-specs-with-worktree` skill for implementing specs in isolated git worktrees.
|
|
@@ -0,0 +1,4 @@
|
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "Implement Specs with Worktree"
|
|
3
|
+
short_description: "Implement an approved spec set inside an isolated git worktree"
|
|
4
|
+
default_prompt: "Use $implement-specs-with-worktree to read the full plan set under docs/plans, create or reuse an isolated git worktree, implement all approved tasks with the required tests, backfill completion status into the planning docs, and commit the result to the local worktree branch without affecting main."
|
|
@@ -20,9 +20,9 @@ description: >-
|
|
|
20
20
|
|
|
21
21
|
## Standards
|
|
22
22
|
|
|
23
|
-
- Evidence: Inspect
|
|
24
|
-
- Execution: Merge
|
|
25
|
-
- Quality:
|
|
23
|
+
- Evidence: Inspect the current branch state, local branches, ahead/behind status, and actual conflicting files before deciding what to merge.
|
|
24
|
+
- Execution: Merge only the relevant local branches into `main` sequentially, resolve conflicts by reading both sides and editing the merged result to preserve shipped behavior, then verify the merged state.
|
|
25
|
+
- Quality: Never use blanket timestamp rules or default `-X ours/theirs` conflict resolution as the primary merge strategy, and do not declare success until the final `main` state has been checked and verified.
|
|
26
26
|
- Output: Produce a clean main branch with all local changes integrated.
|
|
27
27
|
|
|
28
28
|
## Goal
|
|
@@ -34,6 +34,8 @@ Consolidate all local branch changes into the local main branch with automatic c
|
|
|
34
34
|
### 1) Inventory all local branches
|
|
35
35
|
|
|
36
36
|
- Run `git branch` to list all local branches.
|
|
37
|
+
- Check the current branch with `git branch --show-current` and capture `git status -sb`.
|
|
38
|
+
- Compare each candidate branch against `main` with `git log --oneline main..branch`, `git diff --stat main...branch`, or equivalent evidence so empty or already-merged branches are skipped.
|
|
37
39
|
- For each branch, note:
|
|
38
40
|
- Branch name
|
|
39
41
|
- Commits ahead of main
|
|
@@ -41,11 +43,9 @@ Consolidate all local branch changes into the local main branch with automatic c
|
|
|
41
43
|
|
|
42
44
|
### 2) Ensure clean state on main
|
|
43
45
|
|
|
44
|
-
- Check `git status` on main
|
|
45
|
-
- If
|
|
46
|
-
|
|
47
|
-
git stash push -m "WIP: temporary stash before branch merging"
|
|
48
|
-
```
|
|
46
|
+
- Check `git status` on `main`.
|
|
47
|
+
- If `main` has uncommitted changes that are unrelated to the merge request, stop and report them instead of stashing automatically.
|
|
48
|
+
- Only proceed once you can state which branch or branches actually need to be merged.
|
|
49
49
|
|
|
50
50
|
### 3) Merge branches sequentially
|
|
51
51
|
|
|
@@ -62,19 +62,14 @@ For each local branch (excluding main):
|
|
|
62
62
|
```
|
|
63
63
|
|
|
64
64
|
3. If conflicts occur, resolve them automatically using these rules:
|
|
65
|
-
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
- **
|
|
69
|
-
- **
|
|
70
|
-
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
```bash
|
|
74
|
-
git merge -X ours <branch-name> # Prefer main's version for conflicts
|
|
75
|
-
git merge -X theirs <branch-name> # Prefer the merged branch's version
|
|
76
|
-
```
|
|
77
|
-
Or manually edit conflicted files and:
|
|
65
|
+
- Read the conflict markers and both parent versions before editing.
|
|
66
|
+
- **Same line, different content**: keep the version that matches the intended post-merge behavior, not simply the newer edit.
|
|
67
|
+
- **File deleted in one branch, modified in another**: keep the version supported by current code references and tests; do not silently drop reachable code.
|
|
68
|
+
- **Both branches modified the same file differently**: preserve both changes when they are compatible; if they overlap, manually compose a merged result that keeps the verified logic from both sides.
|
|
69
|
+
- **Test files conflicting**: preserve coverage for both behaviors unless one assertion is now obsolete by verified implementation changes.
|
|
70
|
+
- Use `-X ours` / `-X theirs` only for a narrowly justified conflict after reading the actual content; never use those flags as the default merge strategy.
|
|
71
|
+
|
|
72
|
+
After resolving files:
|
|
78
73
|
```bash
|
|
79
74
|
git add <resolved-files>
|
|
80
75
|
```
|
|
@@ -82,7 +77,8 @@ For each local branch (excluding main):
|
|
|
82
77
|
4. If auto-resolution is ambiguous, prefer the change that:
|
|
83
78
|
- Does not break existing tests
|
|
84
79
|
- Preserves the documented feature intent
|
|
85
|
-
-
|
|
80
|
+
- Aligns with the code currently shipped on the source branch
|
|
81
|
+
- Minimizes hidden semantic drift between the merged modules
|
|
86
82
|
|
|
87
83
|
5. Complete the merge:
|
|
88
84
|
```bash
|
|
@@ -91,28 +87,25 @@ For each local branch (excluding main):
|
|
|
91
87
|
|
|
92
88
|
### 4) Verify merged state
|
|
93
89
|
|
|
94
|
-
-
|
|
90
|
+
- After each conflictful merge, run the most relevant targeted tests or build checks for the files that changed.
|
|
91
|
+
- After all merges complete, run the repository's broader validation command when one exists:
|
|
95
92
|
```bash
|
|
96
|
-
# Run tests if a test command exists
|
|
97
93
|
npm test # or yarn test, cargo test, etc.
|
|
98
94
|
```
|
|
99
|
-
- If
|
|
95
|
+
- If verification fails, fix the merged state on `main` before proceeding.
|
|
100
96
|
|
|
101
97
|
### 5) Commit the merged result
|
|
102
98
|
|
|
103
|
-
The merge commits
|
|
104
|
-
|
|
105
|
-
```bash
|
|
106
|
-
git status
|
|
107
|
-
git add -A
|
|
108
|
-
git commit --amend --no-edit # Amend the last merge commit if needed
|
|
109
|
-
```
|
|
99
|
+
- The merge commits are the submission artifact; do not amend them unless the user explicitly asks for history rewriting.
|
|
100
|
+
- If a follow-up fix is required after verification, create a normal commit on `main` that explains the correction.
|
|
110
101
|
|
|
111
102
|
### 6) Report completion
|
|
112
103
|
|
|
113
104
|
- List all branches that were merged.
|
|
105
|
+
- List any branches intentionally skipped because they were already merged, empty, or out of scope.
|
|
114
106
|
- Confirm main is updated with all changes.
|
|
115
107
|
- Note any conflicts that were resolved and the rationale.
|
|
108
|
+
- Report the verification commands that were run.
|
|
116
109
|
- Confirm no remote push was performed.
|
|
117
110
|
|
|
118
111
|
## Working Rules
|
|
@@ -123,14 +116,15 @@ git commit --amend --no-edit # Amend the last merge commit if needed
|
|
|
123
116
|
- If a branch contains no meaningful changes (empty merge), skip it.
|
|
124
117
|
- Keep the main branch history clean and readable.
|
|
125
118
|
- If a branch's merge breaks tests, resolve the conflict differently before committing.
|
|
119
|
+
- Do not stash or discard unrelated work automatically; stop when the working tree state makes the merge ambiguous.
|
|
126
120
|
|
|
127
121
|
## Conflict Resolution Examples
|
|
128
122
|
|
|
129
123
|
| Scenario | Resolution Strategy |
|
|
130
124
|
|----------|---------------------|
|
|
131
|
-
| Same line,
|
|
132
|
-
| Same line, branch
|
|
133
|
-
| File deleted in branch, modified in main | Keep
|
|
125
|
+
| Same line, both branches changed behavior | Read both code paths and compose the merged logic that preserves the verified invariant |
|
|
126
|
+
| Same line, one branch is a bug fix and the other is a refactor | Keep the bug fix and reapply the compatible refactor structure manually if needed |
|
|
127
|
+
| File deleted in branch, modified in main | Keep the version supported by current references/tests and remove only if the deletion is proven correct |
|
|
134
128
|
| Both added same function differently | Keep both; rename if needed |
|
|
135
129
|
| Config file conflict | Keep both values if non-overlapping |
|
|
136
130
|
| Test file conflict | Keep both test cases |
|
|
@@ -0,0 +1,4 @@
|
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "Merge Changes from Local Branches"
|
|
3
|
+
short_description: "Merge relevant local branches into main with verified conflict resolution"
|
|
4
|
+
default_prompt: "Use $merge-changes-from-local-branches to inventory local branches, merge only the relevant ones into local main, resolve conflicts by reading and composing the correct behavior instead of relying on blanket merge strategies, run targeted verification after conflictful merges, and leave remote state untouched."
|
package/package.json
CHANGED