@wairon/cli 5.1.1-dev.46 → 5.1.1-dev.48

package/dist/templates/skills/sdd-delegate.md

@@ -44,3 +44,35 @@ You are the **Delegation Orchestrator**. Your job is to hand scoped work to a fo
    - Read the report, verify the write fence was respected, and continue orchestrating — or delegate the next scoped task.
 
 This flow is transport-agnostic: it works identically over local stdio and the hosted data plane — the tools and `wairon-agent://` resources are the same surface.
+
+## What goes in the brief — and what must not
+
+A brief that re-types the working conventions is a brief that will one day omit
+one, and the omission is invisible: nobody reads a prompt looking for what is not
+in it. The conventions that hold for **any** delegated change live in
+`sdd-implement` under **Working conventions** — never hand-edit specs, read every
+write back, the lock is the human's, measure before repairing, restore a revert
+proof from your own snapshot, refuse with reasoning, report what you did not do.
+Point the subagent at that skill and spend the brief on what only you know:
+
+* **The task and the fence** — `brief.ownedPaths`, `brief.readPaths`, the concrete
+  change, and the branch/commit discipline if the project has one.
+* **What this project does differently** — its gate commands and their current
+  baselines, its tooling or line-ending quirks, the paths that are somebody else's
+  work in flight. Name the project's own contributor doc rather than paraphrasing
+  it: a paraphrase drifts, and the subagent cannot tell which copy is current.
+* **The premise you are asking them to act on**, stated *as* a premise, so it can
+  be contradicted.
+
+## Receiving the report
+
+* **A measurement or a refusal is a delivery, not a failure.** "This lights up 362
+  findings" or "the code does not do what the brief assumes, here is the proof" is
+  the one thing you could not have learned without spending that context. Decide
+  on it. Re-delegating "just fix it" throws the measurement away and buys the same
+  question back later at full price.
+* **Read the part of the report that says what was NOT done.** Skipped gates and
+  untested paths are where the next wave's surprise lives, and a report that lists
+  only successes has not been read until you have looked for that section.
+* **Verify the write fence and the gate numbers yourself** before you build the
+  next delegation on top of this one.

package/dist/templates/skills/sdd-implement.md

@@ -101,6 +101,63 @@ You are the **Spec-to-Code Compiler**. Your job is to generate concrete source c
      coherent, unit tests prove the component honors its CONTRACT shape, and only the
      integration sim proves the wired components RUN together.
 
+## 🧭 Working conventions (what each one cost)
+
+These are not house style. Each one is here because a delegated change went wrong
+without it, and a convention whose reason you can see is one you can still apply
+to the case nobody wrote down.
+
+1. **Specs change through the validated write path — never a text edit.**
+   The `sdd_*` tools (or, in-process, the library's own write function) are what
+   renumber narrative steps, relocate jump targets, and refuse a delta the schema
+   does not accept. Hand-editing a file under `.wai/` skips all three, and the
+   damage surfaces later in somebody else's validate run. If a running server
+   cannot express a field your change introduces, that is a reason to restart it
+   or call the library directly — never a licence to open the editor.
+2. **Read every write back from disk before you build on it.**
+   A write's answer is what the *server* believes. `sdd_update_spec` returns a
+   structured change report naming what actually moved — read it, because
+   "nothing changed" and "everything changed" are different answers that used to
+   be the same sentence — and it sets `staleServer: true` (with a ⚠ STALE SERVER
+   banner) when the build on disk moved after the server started. That flag
+   exists because a stale process once silently replaced an entire `params` list
+   while reporting success. Restart the session when you see it, and open the
+   file either way: the report is evidence, the file is truth.
+3. **The lock is the human's signature, not a step in your task.**
+   Never run `wairon lock`. Your work ends at "the tree validates" — say so and
+   hand it over (`sdd-architect` carries the handoff wording). Locking on the
+   human's behalf forges the one record that says a person looked.
+4. **Measure before you repair.**
+   When a change lights up a large number of findings, report the count and stop.
+   Whether to fix them, carry them, or scope them out is the maintainer's call,
+   and it is cheap to ask before the work and expensive after. Separate *your*
+   breakage from debt that was already there before you report either number: a
+   wave that mixed the two spent its effort across 362 findings and could only
+   honestly claim 224 of them.
+5. **Prove a behaviour by revert — and restore from your own snapshot.**
+   Copy the file aside, overwrite it, run the thing, then restore *from the copy*.
+   Never `git checkout --` to undo the experiment: that restores the *committed*
+   version, so every uncommitted change in that file — yours and anyone else's —
+   dies with the proof. It has already cost about 120 lines of work that nobody
+   could get back.
+6. **Delete the temporary harness before you commit, and say that you did.**
+   A scratch script left behind reads as a deliverable to the next person and
+   quietly becomes a file somebody now maintains. (An integration sim is the
+   opposite case — it is *meant* to stay, committed and declared as `simPath`.)
+7. **A refusal with reasoning is a result.**
+   If the code contradicts the premise you were handed, say so and show the
+   measurement. Building what was asked on a premise you have already disproved
+   spends the work twice and buries the finding.
+8. **Never declare what the code does not do.**
+   A `lint.allow`, a `simPath`, a coverage anchor, or a `status: complete` that
+   silences a finding without the behaviour behind it is worse than the finding:
+   it moves a known defect out of a list somebody reads and into a claim somebody
+   trusts.
+9. **Report what you did not do as carefully as what you did.**
+   The gate you skipped, the path you left untested, the thing you could not
+   reproduce — that is what the next person needs. A report listing only
+   successes gets read as complete.
+
 ## 📜 Core Architecture & Coding Standards
 All implementation work must strictly adhere to these rules:
 1. **Semantic Naming & Stereotypes**:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wairon/cli",
-  "version": "5.1.1-dev.46",
+  "version": "5.1.1-dev.48",
   "description": "SYW Waffle AIron — CLI for managing AI coding agent topology across projects",
   "keywords": [
     "ai",