runcastle 1.0.20 → 1.0.22
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/bin/runcastle.js +357 -60
- package/drizzle/0009_pale_agent_zero.sql +1 -0
- package/drizzle/meta/0009_snapshot.json +610 -0
- package/drizzle/meta/_journal.json +7 -0
- package/index.js +357 -60
- package/package.json +1 -1
- package/skills/burner/resolve-conflict.md +69 -0
- package/web/assets/{index-CnpBTT2-.js → index-BcWKL2hj.js} +20 -20
- package/web/assets/{index-BIDKY6fS.css → index-fWdYT4eC.css} +1 -1
- package/web/index.html +2 -2
package/package.json
CHANGED
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
<!-- Rendered by the ticket-burner when a ticket's branch fails to land on the feature branch. Placeholder tokens are filled in by the workflow. -->
|
|
2
|
+
|
|
3
|
+
# Resolve a landing conflict — unattended
|
|
4
|
+
|
|
5
|
+
You already implemented a ticket. Your commits are on your branch, but they could **not** be landed on the feature branch: while you were working, sibling tickets landed their own commits and you both touched the same files.
|
|
6
|
+
|
|
7
|
+
Your one job now is to **merge the feature branch into your branch and resolve the conflicts**, so your work and theirs both survive. You are not re-implementing anything, and you are not starting new work.
|
|
8
|
+
|
|
9
|
+
There is **no human to ask** — everything you need is in this prompt and in the repo. This is the last automated attempt before a human is pulled in, so be careful, not fast.
|
|
10
|
+
|
|
11
|
+
## How you run
|
|
12
|
+
|
|
13
|
+
You run **non-interactively** (`claude --print`), for up to a few fresh iterations against the same worktree:
|
|
14
|
+
|
|
15
|
+
- **Ending your turn ends your process.** There are no background-task completion notifications in print mode — a "the notification will re-invoke me" plan never fires. Run long commands (test suites) in the foreground with a generous timeout.
|
|
16
|
+
- **Signal completion.** When the merge commit is in, print exactly `<promise>COMPLETE</promise>` as the last line of your final message. Do the same after writing `BLOCKED.md` (see hard rules).
|
|
17
|
+
|
|
18
|
+
## Where to work
|
|
19
|
+
|
|
20
|
+
{{WORKSPACE_NOTES}}
|
|
21
|
+
|
|
22
|
+
## The conflict
|
|
23
|
+
|
|
24
|
+
Merging your branch into `{{FEATURE_BRANCH}}` conflicts on:
|
|
25
|
+
|
|
26
|
+
{{CONFLICT_FILES}}
|
|
27
|
+
|
|
28
|
+
These commits landed on `{{FEATURE_BRANCH}}` while you were working — this is the other side of the merge, the work you must preserve alongside your own:
|
|
29
|
+
|
|
30
|
+
{{OTHER_SIDE}}
|
|
31
|
+
|
|
32
|
+
## The ticket you implemented
|
|
33
|
+
|
|
34
|
+
```json
|
|
35
|
+
{{TICKET_JSON}}
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
## Feature context
|
|
39
|
+
|
|
40
|
+
{{FEATURE_BRIEF}}
|
|
41
|
+
|
|
42
|
+
## Feature docs (spec / decisions digest)
|
|
43
|
+
|
|
44
|
+
{{DOCS_DIGEST}}
|
|
45
|
+
|
|
46
|
+
## How to work
|
|
47
|
+
|
|
48
|
+
1. **Orient before touching anything.** `git log --oneline -15` to see your own commits, then read the conflicting files. Understand what *your* commits were doing there (the ticket above is the intent) and what the *other* side's commits were doing (the log above, plus `git show` on them).
|
|
49
|
+
|
|
50
|
+
2. **Start the merge:**
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
{{MERGE_COMMAND}}
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
It will stop with conflicts. `git status` lists the unmerged paths.
|
|
57
|
+
|
|
58
|
+
3. **Resolve by intent, not by picking a side.** For every `<<<<<<< / ======= / >>>>>>>` hunk, keep *both* behaviours working. Reconcile the logic where the two sides genuinely overlap — the feature docs above are the tie-breaker on intent. Never delete one side's behaviour just to make the conflict go away, and never resolve by taking your whole side (`--ours`) or theirs (`--theirs`) wholesale unless one side is genuinely a strict superset.
|
|
59
|
+
|
|
60
|
+
4. **Watch for semantic conflicts, not just textual ones.** Files that merged cleanly can still be broken by the other side's rename, signature change, or moved export. After resolving the marked hunks, run typecheck and the tests covering both sides' touched code, and fix what the merge broke.
|
|
61
|
+
|
|
62
|
+
5. **Complete the merge.** Stage the resolved files and commit — keep it a merge commit (`git commit --no-verify`, do not `--squash`, do not rebase, do not amend your earlier commits). A merge commit whose message names what was reconciled is ideal.
|
|
63
|
+
|
|
64
|
+
## Hard rules
|
|
65
|
+
|
|
66
|
+
- **Never expand scope.** Resolving the conflict is the whole job. No refactors, no improvements, no adjacent fixes, not even tempting ones in the files you are already editing.
|
|
67
|
+
- **Never lose committed work.** Not yours, not theirs. `git merge --abort` + "start over from one side" is not a resolution.
|
|
68
|
+
- **Never push, and never touch the remote.** The orchestrator lands your branch itself once the merge commit exists.
|
|
69
|
+
- **If the two sides genuinely cannot be reconciled without a product decision** (they implement contradictory behaviour, not merely overlapping code): `git merge --abort`, write `BLOCKED.md` at the repo root naming the exact contradiction and the decision needed, print `<promise>COMPLETE</promise>`, and stop. A human will decide. Do not guess.
|