baxian 1.2.20 → 1.2.22

package/dist/skills/baxian-server-review/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: baxian-server-review
+description: QA reviews injected server-review content (a code diff or a spec doc) — judge against the task spec, write findings.json with a verdict. Covers code review, recheck closure, and spec review.
+disable-model-invocation: true
+---
+
+baxian dispatches you with a block of `key: value` dispatch fields; the review input rides in trailing blocks — `diff:` (code) or `spec:` (spec review), plus `prior-findings:` / `prior-response:` on a recheck. Do NOT fetch branches or use `gh` — those blocks ARE the review input. Work in `worktree:`. QA judges risk independently — human authorization is input, not a bypass. If a `content: truncated` field is present, request the missing context via the read-file side-channel.
+
+Route on `phase:`: `server-review` → §Code Review; `server-recheck` → §Code Review + §Recheck Closure; `server-spec-review` → §Spec Review.
+
+## Code Review
+
+Judge the `diff:` block against the task spec: correctness, tests, edge cases, security, regressions.
+
+- Severity: `critical` = broken/unsafe, `major` = must fix before merge, `minor` = improvement.
+- Reference file + line for every code finding.
+- For unchanged files, read them directly from your own base-branch worktree; use the read-file side-channel only for content not present locally.
+
+## Recheck Closure
+
+The `prior-findings:` and `prior-response:` blocks carry the earlier findings and the dev response. Close them out before judging anything new.
+
+- Resolve the status of EVERY prior finding first.
+- A finding the dev claims fixed → verify it in the new diff. No "fixed" without evidence.
+- A finding the dev rejected / called out-of-scope → judge the rationale on merit; re-raise it with concrete counter-evidence if it is wrong.
+- Any prior finding NOT closed reappears in `findings.json` with its ORIGINAL id and the evidence restated — do not renumber or drop it.
+- Verdict `approve` ONLY when every prior finding is closed AND the new diff is clean. An unresolved finding may not be downgraded to a minor suggestion to justify approve — otherwise `request-changes`.
+- After closure, scan the new diff for regressions AND for behavior the fixes introduced that lacks test coverage.
+
+## Spec Review
+
+Judge the `spec:` block:
+
+- completeness — every requirement covered, interfaces and data flows defined, error paths specified.
+- correctness — internally consistent, no contradicting sections, feasible against the existing codebase.
+- ambiguity — any requirement readable two ways is a finding.
+
+Need a referenced file or codebase section to judge feasibility? Use the read-file side-channel. When `prior-findings:` / `prior-response:` blocks are present, verify every finding is closed before judging the rest of the spec.
+
+## Findings Output
+
+Write findings to `.baxian/review/findings.json` in YOUR worktree (`mkdir -p .baxian/review` first). Atomic write: write `findings.json.tmp` first, then `mv findings.json.tmp findings.json`.
+
+Schema — substitute `<round>` with your `round:` field:
+
+```json
+{"round":<round>,"verdict":"approve"|"request-changes","findings":[{"id":"f-1","severity":"critical"|"major"|"minor","message":"...","file":"path","line":N}]}
+```
+
+Spec-review findings use `"location":"Section ..."` in place of `"file"`/`"line"`.
+
+- Finding ids are `f-1`, `f-2`, … sequential and unique within `findings.json` — the dev coverage check and QA closure verification key off them.
+- `approve` MAY carry minor findings as suggestions; the `verdict` field is authoritative.
+
+Then emit your `signal:` (`code-reviewed` or `spec-reviewed`) with `token:`. Signal wire format and the read-file side-channel: see the **baxian-signals** skill.

package/dist/skills/baxian-server-review/agents/openai.yaml

@@ -0,0 +1,2 @@
+policy:
+  allow_implicit_invocation: false

package/dist/skills/baxian-signals/SKILL.md

@@ -18,22 +18,28 @@ baxian scans the pane fuzzily (strips ANSI escapes and whitespace), so a TUI sof
 
 ## How to emit
 
-The dispatch prompt hands you a template with placeholders plus the literal values on companion lines:
+The dispatch descriptor names the signal kind in a signal field and the token in `token:`. The default completion is `signal:`; some phases also expose an alternate field for an optional branch (e.g. `spec-signal:` on develop's SDD route). Your phase skill's flow tells you which field applies — emit the one for the route you took, never both:
 
 ```
-[bx:pr-fixed:<token>]
+signal: pr-fixed
 token: a1b2c3d4e5f6
 ```
 
-1. Substitute `<token>` with the value on the `token:` line. `<pr_number>` (only `pr-created`, and `code-ready` when publishing as a PR) is the number of the PR you just created/opened with `gh pr create` — the dispatch prompt carries no PR-number line.
+1. Build the wire form `[bx:KIND:TOKEN]` from the field your skill's flow selects — KIND = that field's value (the `signal:` value by default, or an alternate like `spec-signal:`), TOKEN = the `token:` value — and emit it filled. `<pr_number>` (only `pr-created`, and `code-ready` when publishing as a PR) is the number of the PR you just created/opened with `gh pr create` — the descriptor carries no PR-number field.
 2. Emit the filled signal **alone on its own line**.
-3. **Never echo the `<…>` placeholder verbatim** — the scanner's strict regex cannot match angle-bracket placeholders, so a verbatim template echo fires nothing and the task hangs forever waiting on a signal.
-4. Emit the kind the prompt asks for, **exactly once**, only when its precondition holds. baxian consumes the first matching signal whose token matches the active dispatch; the token rotates every dispatch, so a stale or guessed token never fires.
+3. **Never emit an angle-bracket placeholder** like `[bx:pr-fixed:<token>]` verbatim — the scanner's strict regex cannot match placeholders, so it fires nothing and the task hangs forever waiting on a signal.
+4. Emit the single kind your phase skill's flow selects, **exactly once**, only when its precondition holds. baxian consumes the first matching signal whose token matches the active dispatch; the token rotates every dispatch, so a stale or guessed token never fires.
 
 ## Signal catalog
 
 Phase signals — the per-dispatch transition signals baxian consumes to advance a task. The dispatch prompt always names which one to emit and when.
 
+Bootstrap handshake (before any task):
+
+| Signal | Meaning |
+|---|---|
+| `greeting` | one-time capability check at agent startup; prove you can load this skill and signal back. baxian holds the agent until it sees a valid `greeting` echo |
+
 GitHub PR flow:
 
 | Signal | Meaning |

package/dist/skills/baxian-task-check/SKILL.md

@@ -1,35 +1,50 @@
 ---
 name: baxian-task-check
-description: How to analyze a baxian-managed task before starting development
+description: How a dev analyzes and executes a baxian-managed develop/code task — read the structured prompt, plan, run the develop or code flow, signal back.
 disable-model-invocation: true
 ---
 
-Before writing any code, read the task in your prompt — the `Phase:` / `Role:` header followed by the `Title:` line and its description.
+baxian dispatches you with a block of `key: value` dispatch fields followed by the task `title:` and its description. Work in the directory named by `worktree:` — cd there before any file operation. Route on `phase:`: `develop` → §Develop, `code` → §Code.
 
-## Steps
-1. Read the prompt's `Title:` line and description — the authoritative task source (no `.baxian/task.md` file).
-2. Identify acceptance criteria.
-3. Plan: files to modify, tests to write.
+If an `images:` list is present, read each path (baxian downloaded the user's uploads to the agent host) and factor them into the task.
 
-## What to look for
-- Explicit vs implied requirements
-- Edge cases
-- File/function references
-- Linked docs, screenshots, specs
+## Analyze
 
-## When to ask vs. proceed
+1. Read `title:` and the description — the authoritative task source (no `.baxian/task.md` file).
+2. Identify acceptance criteria, explicit vs implied requirements, edge cases, file/function references, linked docs/specs.
+3. Plan the files to modify and the tests to write.
+
+When to ask vs proceed:
 - Clear → start.
-- Missing info + PR exists → record in PR description.
-- Missing info + no PR → pick reasonable interpretation, write assumption after `<!-- baxian:managed -->` marker (marker MUST be line 1), or create task if blocked.
-- Minor ambiguity → proceed, note in PR.
-- Always record assumptions (PR, task, or commit message).
+- Minor ambiguity → proceed, record the assumption (PR description, task note, or commit message).
+- Blocked → pick a reasonable interpretation and record it after the `<!-- baxian:managed -->` marker (marker MUST be line 1), or create a task if truly blocked.
+
+## Conventions
+
+Your `exchange:` field selects the cross-agent medium:
+- `github-pr` — communicate via the GitHub PR (description, commits, reviews, comments). A managed PR's description first line MUST be `<!-- baxian:managed -->`. Stay in scope — out-of-scope work goes to a new GitHub Issue.
+- `server-files` — baxian reads your worktree directly; do NOT push or open a PR (the publish phase does that). Stay in scope.
+
+A PR you open MUST be ready for review (not Draft): do NOT use `--draft`; if it is draft after creation, run `gh pr ready` before signaling.
+
+## Develop
+
+Two mutually-exclusive routes — pick ONE and emit only its signal:
+
+- **SDD** (only when a `spec-signal:` field is present, i.e. a QA partner exists) — get your design reviewed first: follow §Specification-Driven Development, then emit `spec-signal:` (`spec-done`) with `token:`. Do NOT emit the default `signal:` on this route — that would skip spec review and push an unimplemented task forward. After QA approves the spec, baxian dispatches the code phase. Use SDD when the design is non-trivial; skip it when the change is small or unambiguous.
+- **Direct** — implement the change, then emit `signal:` with `token:`: `exchange: github-pr` → after `gh pr create` (ready for review), emit `pr-created`; `exchange: server-files` → after a local commit (do NOT push), emit `code-done`.
+
+## Code
+
+The spec is approved at `.baxian/spec.md`. Implement it, then emit your `signal:` with `token:`:
+- `exchange: github-pr` → commit + push, `gh pr create` (ready for review), emit `pr-created`.
+- `exchange: server-files` → local commit only (do NOT push, no PR), emit `code-done`.
 
 ## Specification-Driven Development (SDD)
 
-Optional, and offered only when the dispatch prompt gives you a `spec-done` signal (a QA partner exists). Use it to have QA review your design before you write code.
+Use it to have QA review your design before you write code.
 
 - Write the spec to `.baxian/spec.md` in your worktree. Do NOT commit or push it — baxian reads the file directly for QA review.
-- Then emit the `spec-done` signal the prompt gives you (with its token). Signal wire format and emit rules: see the baxian-signals skill.
-- Skip it and implement directly when the change is small or the design is unambiguous.
+- Then emit the `spec-signal:` (`spec-done`) with `token:`.
 
-After QA approves the spec, baxian dispatches the code phase to implement it.
+Signal wire format and emit rules: see the baxian-signals skill.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "baxian",
-  "version": "1.2.20",
+  "version": "1.2.22",
   "description": "AI agent orchestration",
   "license": "Apache-2.0",
   "repository": {