@webappwiz/cli 0.0.5 → 0.0.7

package/{index-0kf75kja.js → index-6km6e845.js}

@@ -2,7 +2,7 @@ import {
   table
 } from "./index-jbrs6gqt.js";
 // package.json
-var version = "0.0.5";
+var version = "0.0.7";
 
 // skills/add.ts
 import { ConsoleLogger } from "webappwiz/log";
@@ -15,7 +15,7 @@ import { dirname } from "node:path";
 var arbor_skill_default = `---
 name: arbor
 description: Use the @webappwiz/arbor CLI to land your work on trunk, or a base branch given as an argument, from an isolated git worktree without pull requests. Read this before making any code change in an arbor repository, since it decides where the work happens, and whenever you need to add, claim, merge, remove, list, show, locate, or escalate a task.
-version: 0.0.5
+version: 0.0.7
 ---
 
 # Using arbor
@@ -41,9 +41,12 @@ its changed files:
 \`git -C "$(arbor path <task>)" diff --name-only main...task/<task>\`
 (\`arbor show <task>\` for its plan; neither takes its lease).
 
-If nothing overlaps, carry on. If something does, wait for it to land rather
-than buying a rebase conflict: say one line about what you are waiting on,
-then re-check periodically. A status is only true for the moment you read it,
+If nothing overlaps, carry on. If something does, do not pick a side
+yourself: \`arbor add\` your task if you have not already, record the overlap
+in \`ARBOR.md\` (which task, which files), then \`arbor escalate\` and ask the
+user whether to wait for the other task, work alongside it and accept the
+rebase, or drop yours. If they choose to wait, re-check periodically. A
+status is only true for the moment you read it,
 so re-run \`arbor ls\` every time you are about to repeat one. Act on what it
 becomes:
 
@@ -76,27 +79,63 @@ command runs): when waiting, watch a task's status, never its lease.
 
 A successful merge deletes the worktree, and your working directory with it:
 \`cd\` to the main tree (merge prints its path) before running anything else.
-Then report it:
 
-\`\`\`\`markdown
+## Escalation
+
+Merge only work you verified yourself. Escalate instead when verification
+needs a person: external services, destructive migrations, anything tests
+cannot confirm. And if the user asked to see the work before it lands,
+escalate regardless.
+
+1. \`arbor escalate <reason>\`.
+2. Under \`## Blocked\` in \`ARBOR.md\`, state what needs verifying, ending in a
+   question a yes/no or a sentence can answer.
+3. Leave something the human can look at and print its **absolute path**
+   (start from \`arbor path <task>\`). For anything visual or UX, that means a
+   screenshot; if producing one is expensive or has side effects, ask before
+   starting and say what it will cost.
+
+If you claim a tree whose \`## Blocked\` question is unanswered, do not resume
+or merge: ask the user and wait for the answer.
+
+## Reporting
+
+However a task ends, say so in one block; only a merge names a base:
+
+\`\`\`markdown
 ### ✅ Merged \`<task>\` onto \`<base>\`
 
-One sentence blending what the task set out to do with what actually changed.
-\`\`\`\`
+One sentence blending what the task set out to do with where it ended up.
+\`\`\`
+
+\`\`\`markdown
+### ⚠️ Escalated \`<task>\`
 
-✅ for a merge, ❌ for a task you \`arbor rm\`ed instead. Anything else worth
-saying goes after this block, not instead of it.
+One sentence blending what the task set out to do with what it now waits on.
+\`\`\`
+
+\`\`\`markdown
+### 🛑 Removed \`<task>\`
+
+One sentence blending what the task set out to do with why you \`arbor rm\`ed
+it instead.
+\`\`\`
+
+Anything else worth saying goes after this block, not instead of it.
 
 ## ARBOR.md
 
 Your session can die at any moment; \`ARBOR.md\` is what lets a stranger
 \`arbor claim\` the task and continue. Fill in \`## Goal\` (one or two lines on
-what done means) and list every step you can foresee under \`## Next\` as
-\`- [ ]\` items, roughly one commit each. Move items to \`## Done\` as you finish
-them: those checkboxes are the only progress the task reports. Decisions,
-dead ends and how to verify go under \`## Notes\`. Update it as each step
-lands, during implementation rather than at the end; a stale plan is worse
-than none, and a session that dies mid-task reports nothing.
+what done means), list the file paths you plan to touch under \`## Files\`,
+and list every step you can foresee under \`## Next\` as \`- [ ]\` items,
+roughly one commit each. Move items to \`## Done\` as you finish them: those
+checkboxes are the only progress the task reports. Decisions, dead ends and
+how to verify go under \`## Notes\`. Keep the whole file current throughout
+implementation, not at the end: after each step lands, check it off, and
+when the set of files you are touching changes, change \`## Files\` to match.
+A stale plan is worse than none, and a session that dies mid-task reports
+nothing.
 
 \`arbor show <task>\` prints the file and every way it departs from the
 expected shape; run it on your own task after writing the file. \`add\` excludes
@@ -110,24 +149,6 @@ Plain, human-style commit messages with **no attribution**: no
 \`--author\` overrides. Commit as often as it helps you; a task usually takes
 fewer than 5 commits, and wanting many more means the task wants splitting,
 not squashing.
-
-## Escalation
-
-Merge only work you verified yourself. Escalate instead when verification
-needs a person: external services, destructive migrations, anything tests
-cannot confirm. And if the user asked to see the work before it lands,
-escalate regardless.
-
-1. \`arbor escalate <reason>\`.
-2. Under \`## Blocked\` in \`ARBOR.md\`, state what needs verifying, ending in a
-   question a yes/no or a sentence can answer.
-3. Leave something the human can look at and print its **absolute path**
-   (start from \`arbor path <task>\`). For anything visual or UX, that means a
-   screenshot; if producing one is expensive or has side effects, ask before
-   starting and say what it will cost.
-
-If you claim a tree whose \`## Blocked\` question is unanswered, do not resume
-or merge: ask the user and wait for the answer.
 `;
 
 // skills/skill.ts

package/index.js

@@ -6,7 +6,7 @@ import {
   update,
   update1 as update2,
   version
-} from "./index-0kf75kja.js";
+} from "./index-6km6e845.js";
 import {
   JUDGE_RULES,
   SIGNOFF_RULES

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@webappwiz/cli",
-	"version": "0.0.5",
+	"version": "0.0.7",
 	"description": "The webappwiz CLI: judge code against rules, sign off a diff, and manage agent skills",
 	"license": "MIT",
 	"author": "Jared Johnson",
@@ -17,8 +17,8 @@
 		"access": "public"
 	},
 	"dependencies": {
-		"@webappwiz/rules": "^0.0.5",
-		"webappwiz": "^0.0.5"
+		"@webappwiz/rules": "^0.0.7",
+		"webappwiz": "^0.0.7"
 	},
 	"peerDependencies": {
 		"typescript": "^7"

package/webappwiz.js

@@ -4,7 +4,7 @@ import {
   update,
   update1 as update2,
   version
-} from "./index-0kf75kja.js";
+} from "./index-6km6e845.js";
 import {
   JUDGE_RULES,
   SIGNOFF_RULES