@henryqw/pi-pr 4.0.2 → 4.0.4

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@henryqw/pi-pr",
3
- "version": "4.0.2",
3
+ "version": "4.0.4",
4
4
  "description": "Run /pr to safely discover or link the current pull request, then create, update, address feedback, fix CI, or merge when ready.",
5
5
  "keywords": [
6
6
  "pi-package",
@@ -33,7 +33,11 @@
33
33
  },
34
34
  "dependencies": {
35
35
  "@henryqw/pi-config-store": "^1.1.0",
36
- "@henryqw/pi-herdr": "^0.4.5"
36
+ "@henryqw/pi-herdr": "^0.4.5",
37
+ "proper-lockfile": "^4.1.2"
38
+ },
39
+ "devDependencies": {
40
+ "@types/proper-lockfile": "^4.1.4"
37
41
  },
38
42
  "repository": {
39
43
  "type": "git",
@@ -5,12 +5,12 @@ description: Prepare and publish the current branch pull request with determinis
5
5
 
6
6
  # Pi PR Create
7
7
 
8
- Use the `pi_pr_create` helper for base, merge, push, upstream, and GitHub mechanics. Do not reproduce its checks or commands with shell tools.
8
+ Use only `pi_pr_create` for base selection, merge, push, upstream, and GitHub work. Do not repeat its Git or GitHub checks with shell tools.
9
9
 
10
- Use the prepared base and merge-base to inspect the live change. Separate pending work into coherent commits. Preserve coherent existing staging. Exclude `.context/` and unrelated changes. Stop when changes cannot be separated safely.
10
+ Start with the prompted `prepare` action. It uses the saved branch base: explicit `/pr --base BRANCH`, one `branch.<branch>.gh-merge-base` value, then validated `origin` default. It requires a committed change ahead. Dirty work alone cannot start this route. The base is always `origin`; fork heads must share its GitHub source and host. Apply trailing prompt guidance only to the PR content.
11
11
 
12
- If the helper reports conflicts, inspect only its returned paths and bounded conflict hunks. Resolve only clear intent, then declare the complete resolved path set to the helper. Ask the user when the correct behavior is unclear.
12
+ After `prepare`, inspect the returned base and merge-base. Separate and commit coherent pending work. Preserve coherent staging. Exclude `.context/` and unrelated changes. Stop when separation is unsafe.
13
13
 
14
- Choose and run the smallest relevant validation after the helper verifies the merge. Stop on failure.
14
+ Use this action order: `prepare`, `merge`, optional `continue`, `push`, then `publish`. On conflict, inspect only returned paths and bounded hunks. Give `continue` every resolved path. Run the smallest relevant validation after the helper verifies the merge.
15
15
 
16
- Write a concise Conventional Commit title. Write a body with `Summary` and `Testing` sections that matches the live diff and checks. Give both to the helper only after it has published the captured head. Reply with only the helper's validated pull request URL.
16
+ Give `publish` a concise Conventional Commit title and a body with `Summary` and `Testing`. It validates the exact PR before no-target upstream setup. If that setup fails after publication, retry `publish` with the same title and body. Do not push again or create another PR. Reply only with the validated PR URL.