microduck-cli 0.7.0__tar.gz → 0.9.0__tar.gz

{microduck_cli-0.7.0 → microduck_cli-0.9.0}/.claude/skills/cicd/SKILL.md

@@ -163,14 +163,27 @@ only when the user explicitly asks for one of them.
 
 For every comment, decide **FIX** or **PUSHBACK** with reasoning.
 
-Default to **FIX** for: portability complaints (always valid for
-Steward — recurring bug class), test or doc requests, style nits
+Default to **FIX** for: portability complaints (a recurring bug
+class across AgentCulture repos), test or doc requests, style nits
 aligned with workspace conventions.
 
 Default to **PUSHBACK** for: architecture opinions that conflict with
-workspace `CLAUDE.md` or the all-backends rule; greenfield
-false-positives (e.g. "add tests" before there's any source — defer
-to a later PR, don't refuse).
+`CLAUDE.md` or the all-backends rule; scaffold false-positives — the
+duck layer is still landing, so "this CLI doesn't do anything with the
+robot yet" is a roadmap item, not a PR defect. "The tick engine belongs
+upstream in `neurosymbolic-system`" is also a PUSHBACK: decision c20
+(recorded in `CLAUDE.md`) puts the engine in `microduck_cli/behavior/`
+now, built extraction-first, with `neurosymbolic-system` extracted later
+from reachy-mini-cli plus this engine.
+
+What a reviewer should check instead is that the **seams stay pure**, so
+the later extraction is a move and not a rewrite: `TargetSink` and
+`SenseProviders` remain the only ways a pose leaves and a reading enters;
+`tick_seam` remains the ONE per-tick integration point (a second loop or
+a second process IS a defect); rules stay data, not code; there is one
+admission registry; liveness stays a heartbeat, not a flag file; and
+nothing under `behavior/` imports a transport, an SDK, or a CLI module
+beyond `cli/_errors`. A comment naming one of those is a **FIX**.
 
 ### Alignment-delta rule
 
@@ -179,18 +192,29 @@ If the PR touches `CLAUDE.md`, `culture.yaml`, or anything under
 PUSHBACK on each comment. Note any sibling that needs a follow-up PR
 and mention it in your reply.
 
-## Greenfield-aware steps
+## Pre-PR steps (microduck-cli)
 
-The lint and the workflow script are always-on. Stack-specific steps
-are conditional and currently no-op (greenfield repo):
+**Consumer adaptation** — upstream ships this section as conditional
+"greenfield-aware" no-ops. microduck-cli's stack has landed, so the steps
+below are unconditional here; run all of them before `workflow.sh open`.
+Recorded as a tracked divergence in `docs/skill-sources.md`.
 
 ```bash
-[ -d tests ] && [ -f pyproject.toml ] && uv run pytest tests/ -x -q
-[ -f pyproject.toml ] && bump_version_per_project_convention   # see project README
-[ -f .markdownlint-cli2.yaml ] && markdownlint-cli2 "$(git diff --name-only --cached '*.md')"
+uv run pytest -n auto                                # full suite must be green
+uv run black --check microduck_cli tests             # the CI lint job, locally
+uv run isort --check-only microduck_cli tests
+uv run flake8 microduck_cli tests
+uv run bandit -c pyproject.toml -r microduck_cli
+uv run teken cli doctor . --strict                   # the agent-first rubric gate
+markdownlint-cli2 "**/*.md" "#node_modules" "#.local" "#.claude/skills" "#.teken"
+/version-bump patch|minor|major                      # REQUIRED on every PR
 ```
 
-Revisit each line as the corresponding stack element actually lands.
+The version bump is not optional: the `version-check` job compares
+`pyproject.toml` against `origin/main` and fails the PR when they match — even
+for docs/config/CI-only changes. Use the `version-bump` skill so `CHANGELOG.md`
+gets its Keep-a-Changelog entry in the same pass.
+
 A `pr lint --extra=tests,version,markdown` ask is filed upstream
 ([devex#41](https://github.com/agentculture/devex/issues/41)).
 
@@ -203,6 +227,9 @@ in the fix-up commit message.
 The `status` extension queries SonarCloud directly (it predates the
 upstream Sonar integration in `devex pr read`). Both surfaces are
 trustworthy — `devex pr read` for display in the briefing, `status` for
-the gate. Steward isn't yet a registered mesh agent, so the
+the gate. microduck-cli isn't yet a registered mesh agent, so the
 post-merge IRC ping that Culture's `pr-review` includes is still
-skipped — that returns when Steward joins the mesh.
+skipped — that returns when microduck-cli joins the mesh. (Until then,
+a cross-repo follow-up — e.g. a runtime gap that belongs to
+`neurosymbolic-system` — goes out as a tracked issue via the
+`communicate` skill.)

microduck_cli-0.9.0/.claude/skills/operate-microduck/SKILL.md

@@ -0,0 +1,232 @@
+---
+name: operate-microduck
+description: >
+  Open the MicroDuck simulation with its MuJoCo window, operate the duck —
+  stand it up, enable its policy, run skills, turn its head, send motion,
+  drive the data-only rules engine, monitor and record its senses — and close
+  the simulation down again when the user is done. Drives the `microduck` CLI
+  (`env up` / `duck` / `rules` / `env down`) end to end, including the
+  screenshot recipe for watching the MuJoCo window from a headless session.
+  First-party to microduck-cli — authored here, not vendored. Use when the
+  user says "operate the duck", "open the simulation", "start the sim",
+  "close the sim", "make the duck stand / walk / look / quack", or asks to
+  see what the duck is doing.
+type: command
+---
+
+# operate-microduck — open the sim, drive the duck, close it down
+
+The skill is named **`operate-microduck`**. It is the operator front door to
+the `microduck` CLI: one lane from a cold box to a standing duck in a MuJoCo
+window, through the verbs that move it, and back down to nothing running.
+
+## When to use
+
+- The user asks to **open / start the simulation** (with or without a window).
+- The user asks to **make the duck do something** — stand, enable, run a
+  skill, look somewhere, move, quack, or react to rules.
+- The user wants to **watch** the duck (a screenshot of the MuJoCo window) or
+  **record** what it senses.
+- The user asks to **close the sim** / tear the stack down.
+
+Do *not* use it to change the CLI's code — that is ordinary repo work. This
+skill operates the shipped CLI; it does not modify it.
+
+## Prerequisites
+
+1. **Two sibling clones at the pinned commits** in
+   [`docs/upstream-pins.md`](../../../docs/upstream-pins.md):
+   `pollen-robotics/microduck` (branch `sim-remote-io`) and
+   `pollen-robotics/microduck_rl` (branch `develop`). Re-pinning is a
+   deliberate, separate act — never bump a clone to drive the duck.
+2. **`microduck env doctor` must be healthy.** Run it first, every time:
+
+   ```bash
+   uv run microduck env doctor
+   ```
+
+   It exits `2` and names each failing check's remediation when the box is not
+   ready (clones, cargo toolchain, built daemons, the `microduck_rl` venv with
+   `onnxruntime`, a short-enough state dir, a free `duck-body` port, host
+   class, optional credentials). Do not proceed on a `2`.
+3. **Environment variables** — all optional, all with defaults:
+
+   | Variable | Default | What it points at |
+   |---|---|---|
+   | `MICRODUCK_CLONE` | `../microduck` | the `microduck` checkout |
+   | `DUCK_SIM_RL` | `../microduck_rl` | the `microduck_rl` checkout |
+   | `DUCK_SIM_STATE` | `~/.cache/duck-sim` | pidfiles, sockets, engine state |
+
+   The operator never types a socket path, a params file or an ORT path — the
+   CLI derives all three.
+
+## Open the simulation
+
+```bash
+uv run microduck env up --sim                 # MuJoCo body, window on the box's display
+uv run microduck env up --sim --headless      # MuJoCo body, no window
+uv run microduck env up --fake                # single-process stand-in, for sanity/tests
+```
+
+- `--sim` runs the real `duck-body` MuJoCo simulator behind `robotd --sim`
+  (120 s health timeout). A **window** appears on the box's display — so when
+  you are driving from a headless session, the display owner's `DISPLAY` and
+  `XAUTHORITY` must be exported into the command's environment (see
+  *Watch it* below), otherwise the body cannot open one.
+- `--headless` is the same body with no window. Use it when nobody is
+  watching; it is also the safe default over SSH.
+- `--fake` is `robotd --fake`: no physics, no window, 60 s timeout. Use it for
+  a sanity check or when the user just wants the verbs exercised.
+- Add `--skip-build` when the daemons are already built.
+
+Then stand the duck up and hand it to its policy:
+
+```bash
+uv run microduck duck init --apply     # power the joints, ramp to home (~8 s to stand)
+uv run microduck duck enable --apply   # hand the robot to its policy — it holds a stance
+```
+
+`init` takes roughly **eight seconds** to finish standing. Do not judge the
+duck before it has.
+
+## Operate
+
+```bash
+uv run microduck duck health              # the robot's own verdict; exit 2 when unhealthy
+uv run microduck duck version             # API version, daemon version, build revision
+uv run microduck duck monitor --frames 5 --json   # N state frames, one JSON object each
+```
+
+**Look** — point the head at a trunk-frame point:
+
+```bash
+uv run microduck duck look --x 0.2 --y 0.4 --z -0.1 --apply
+```
+
+Pick a **visibly large** target. `--x 0.2 --y 0.4 --z -0.1` turns the head
+about 60° — obvious in the window. Small offsets move the head a couple of
+degrees and read as "nothing happened"; if the user asked to see the duck
+look somewhere, use a big target.
+
+**Skills** — the one-shot moves the daemon knows:
+
+```bash
+uv run microduck rules check --duck duck-a   # lists the skills this daemon actually has
+uv run microduck duck do roulade --apply
+```
+
+Never guess a skill name. `rules check --duck` reads the live snapshot (from
+`robot.subscribe` on API 16) and tells you what exists.
+
+**Move** — drive at intent rate for a duration, then stop:
+
+```bash
+uv run microduck duck move --vx 0.15 --duration 3 --apply
+```
+
+**Say this before you run it:** at the pinned commits the walk network is
+selected and the twist reaches the daemon, but its joint targets are static —
+**the duck leans, it does not take steps.** Locomotion is *not* achieved at
+this pin; see
+[`docs/verification/2026-09-04-sim-bringup.md`](../../../docs/verification/2026-09-04-sim-bringup.md)
+("Walking in the MuJoCo body — not achieved at this pin"). Promising a walk
+and delivering a lean is the failure mode this paragraph exists to prevent.
+
+**Voice and recording:**
+
+```bash
+uv run microduck duck quack                       # this robot's own voice
+uv run microduck duck record > senses.jsonl       # pure JSONL on stdout
+```
+
+**Rules** — the data-only reaction layer and its 50 Hz tick engine:
+
+```bash
+uv run microduck rules list                       # merged config (shipped + overlay) by origin
+uv run microduck rules check --rules ./my.toml --duck duck-a
+uv run microduck rules intent look                # one intent through the ONE registry
+uv run microduck rules engine run --duck duck-a --rules ./my.toml --apply --max-ticks 300
+```
+
+`rules engine run` is the **only** process that opens the duck's control
+socket: connect → `hello` → `health` → `init` → `enable` → armed, each step
+logged on stderr. Always bound an operator run with `--max-ticks N` (300 ticks
+≈ 6 s at 50 Hz) unless the user asked for a long-running engine. On any
+abnormal exit it releases what it energized; it never sends `robot.relax`.
+
+**The human-driving gate.** While a human is driving — a recent `pad.report`,
+`pad_active`, or `robot.remoteSessionActive` — the engine withholds every
+motion channel it composed. robotd arbitrates nothing between clients, so if
+someone picks up the pad the engine gets out of the way rather than fighting
+for the socket. If the duck "ignores" the engine, check whether a pad is live
+before debugging anything else.
+
+**What `--apply` means.** Every verb that moves hardware goes through the same
+gate: on a TTY it asks for confirmation; on a pipe **without** `--apply` it
+prints a zero-side-effect dry-run plan and sends nothing; on a pipe **with**
+`--apply` it proceeds (agent mode). So an agent driving this CLI must pass
+`--apply` deliberately — and a command that printed a plan did *not* move the
+duck.
+
+## Watch it
+
+The MuJoCo window lives on the box's graphical session, not in your terminal.
+To capture it from a headless session, export the **display owner's** session
+environment into the screenshot command — `DISPLAY`, `XAUTHORITY`, and the
+session `DBUS_SESSION_BUS_ADDRESS` — then take the shot:
+
+```bash
+# Discover the display owner's environment rather than hard-coding it:
+#   - the X display and cookie:  the desktop session's DISPLAY / XAUTHORITY
+#   - the session bus:           tr '\0' '\n' < /proc/<gnome-shell-pid>/environ \
+#                                  | grep '^DBUS_SESSION_BUS_ADDRESS='
+export DISPLAY=<the session's display>
+export XAUTHORITY=<the session's X authority file>
+export DBUS_SESSION_BUS_ADDRESS=<the gnome-shell session bus>
+gnome-screenshot -f /tmp/duck.png
+```
+
+Then read the PNG back. Two shots a few seconds apart are the honest way to
+tell motion from a static pose (this is how the "no gait" finding above was
+made). If no graphical session exists, say so and use `--headless` plus
+`duck monitor --json` instead of pretending to have looked.
+
+## Close the simulation
+
+```bash
+uv run microduck env down      # stop every process env up started
+uv run microduck env status    # verify: nothing tracked is alive
+```
+
+`env down` reads each pidfile under the state directory, deletes it *before*
+signalling, and signals a pid only when `/proc/<pid>/cmdline` still names the
+binary that pidfile was written for. **Never kill by name** — no `pkill`, no
+`killall`, no `kill $(pgrep robotd)`. Pids are recycled; a name-based kill can
+take out something else entirely.
+
+## Hard rules
+
+- **Never `relax` a duck someone wants standing without saying what it does.**
+  `duck relax` cuts power and the robot *collapses*. It is gated and wants
+  `--yes`; if the user asks for it, state the consequence first.
+- **Never send motion without `--apply` on a pipe** and then claim the duck
+  moved. A dry-run plan is a plan, not an action — report it as one.
+- **Tear down what you started.** If you brought the stack up for a task, take
+  it down when the task ends: `env down`, then `env status` to prove it.
+- **Leave the window up if the user is watching — and say so.** When the user
+  is looking at the MuJoCo window, do not run `env down` at the end of a step;
+  tell them the stack is still up and how to close it.
+- **Do not smooth over what does not work.** Locomotion at this pin, the API-16
+  method gaps (`robot.policies`, `policy.*` answer `-32601`), a missing display
+  — report them as they are.
+
+## Provenance
+
+**First-party to `microduck-cli`.** Origin = this repo; it is *not* vendored
+from guildmaster, and the cite-don't-import rule points the other way for it:
+guildmaster may broadcast this skill to the AgentCulture mesh, and downstream
+consumers cite this copy rather than editing their own. The canonical copy is
+`.claude/skills/operate-microduck/SKILL.md` in `microduck-cli`; an agent in
+another runtime copies it verbatim, or writes it from the recipe
+`microduck learn` prints ("Authoring the operator skill"). Fixes belong here,
+upstream — never patched locally in a consumer.

microduck_cli-0.9.0/.claude/skills/validate-delivery/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: validate-delivery
+description: >
+  Run the confirmed plan's behavioral tests agent-side after
+  assign-to-workforce merges its waves and before summarize-delivery closes
+  the loop, then file what was found — evidence for what passed, behavioral
+  deltas for what the run added, amended, or removed — as first-class,
+  record-only entries via the devague CLI. Never runs the tests inside the
+  CLI (issue #20); never suppresses a failing or partial outcome. Use when
+  the user says "validate delivery", "run behavioral tests", "check what
+  actually behaves", "file evidence", "record a behavioral delta", or after
+  assign-to-workforce merges (or fails to merge) a plan's waves and before
+  summarize-delivery runs. Authored and maintained in agentculture/devague
+  (origin = devague); guildmaster pulls this skill from here and broadcasts
+  it to the AgentCulture mesh — it is NOT vendored from guildmaster like the
+  inbound skills here.
+type: command
+---
+
+# validate-delivery — run behavioral tests, file evidence and deltas
+
+The skill is named **`validate-delivery`**; it is the **execution-to-evidence
+leg** of the devague method — the *seventh* leg in flow order (the *eighth*
+origin skill, chronologically), sitting between the two closing execution
+skills:
+
+```text
+scope -> think -> challenge -> spec-to-plan -> assign-to-workforce ->
+deviate -> validate-delivery -> summarize-delivery
+```
+
+Where `/assign-to-workforce` fans out a converged plan's waves and
+`/summarize-delivery` closes the loop afterward, `/validate-delivery` runs
+**after waves merge and before the delivery summary is written**. It is the
+gap that used to be filled by memory: the confirmed plan's claims are
+obligations, and until this skill existed nothing forced the run to check
+whether the merged code actually behaves as claimed before the summary
+asserted it did.
+
+## When to invoke
+
+Run this skill once a wave (or the whole plan) has merged and there is
+behavior to check against a claim or an approved deviation — always before
+`/summarize-delivery`, never as a substitute for it. It is not gated on a
+complete run: a partial or failed fan-out is still worth validating for
+whatever did merge.
+
+## The method
+
+1. **Identify the obligations.** Read the plan's confirmed claims (via the
+   frame) and any approved `/deviate` records to see what the run promised —
+   an announcement, an after-state, a success signal, an acceptance
+   criterion. Each one that has a behavioral test backing it is an
+   obligation this leg checks.
+2. **Locate the behavioral tests.** Consuming repos identify behavioral
+   tests one of two ways (either is valid; pick whichever the repo already
+   uses, and say which one in the filed evidence):
+   - a **pytest marker**, e.g. `@pytest.mark.behavioral` — run with
+     `pytest -m behavioral`;
+   - a **dedicated folder**, e.g. `tests/behavioral/` or
+     `behavioral-tests/` — run that path directly.
+3. **Run the tests agent-side.** The agent (not the devague CLI) executes
+   the behavioral test suite, or the specific tests relevant to the
+   obligations in scope. This is read-only against the codebase — it does
+   not modify code to make a test pass.
+4. **File evidence for every obligation checked.** For each obligation, file
+   an evidence record naming the obligation met, the test that asserted the
+   behavior, and the outcome — `pass` or `fail`. A failing outcome is filed
+   exactly like a passing one; it is never omitted or reworded into
+   something softer.
+5. **File behavioral deltas for what changed.** When the run's actual
+   behavior added, amended, or removed a behavior relative to the plan, file
+   a delta record — `added` / `amended` / `removed` — with provenance back
+   to the claim or approved deviation that motivated it, and forward to the
+   evidence record(s) that back it.
+6. **Report faithfully.** Summarize what was validated, what passed, what
+   failed, and what could not be checked at all (no behavioral test exists
+   for that obligation yet). An unmet obligation is unmet — it is reported
+   as such, not folded into a passing tally or left out of the report.
+7. **Hand off to `/summarize-delivery`.** The filed evidence and deltas feed
+   directly into `devague summary`'s Delivery Claims table: evidence
+   strength (coverage / fidelity / execution / sensitivity) is the
+   confidence vocabulary there, and any approved lapse on a claim caps its
+   confidence the same way it always has.
+
+## The CLI surface this skill drives
+
+**Record-only.** The devague CLI never runs a test itself (issue
+[#20](https://github.com/agentculture/devague/issues/20)) — it only records
+what the agent already ran and found. The exact verb shapes below are
+minimal placeholders while the underlying schema lands in a parallel task;
+treat the verb names as stable and the flags as illustrative, and reconcile
+against `devague explain <move>` once that task merges.
+
+| Move | What it records |
+|------|------------------|
+| `devague oblige <cN> --seam "<seam>" --behavior "<behavior>"` | Files a behavioral obligation against a claim, naming the seam to test and the behavior to assert (snapshots the claim text at filing). |
+| `devague evidence --obligation <oN> --test "<ref>" --behavior "<asserted>" --contract "<claim text>" --type <type> --strength <level> --basis "<basis>" --outcome pass\|fail [--run-commit <sha> --run-timestamp <ts>]` | Files an evidence record: obligation met by this test, asserting this behavior, outcome pass or fail (a run reference is required at execution strength and above). `llm`-origin filings land `proposed`; the human adjudicates. |
+| `devague delta --kind added\|amended\|removed --behavior "<what changed>" --caused-by <cN\|dN> [--evidence <eN> ...]` | Files a behavioral delta: provenance back to the claim/deviation it diverges from (`--caused-by`), forward to the evidence that backs it. |
+| `devague summary [--pr] [--json]` | Reads the filed evidence and deltas back into the Delivery Claims table (`/summarize-delivery`'s starting point). |
+
+`--origin llm` on `oblige` / `evidence` / `delta` lands the record `proposed`
+— exactly the same anti-fabrication contract as `deviate` and `lapse`: an
+agent's own filing never self-confirms, and only the human's `--confirm` /
+`--reject` moves a proposed record forward. A `user`-origin filing
+auto-approves, mirroring `deviate` and `lapse`.
+
+## Hard rules (do not violate)
+
+- **The CLI never runs tests.** `devague oblige` / `evidence` / `delta` are
+  record-only moves — they take the agent's already-obtained result and
+  file it. Running the suite is the agent's job, agent-side, exactly like
+  `/summarize-delivery`'s read-only verification step (issue #20).
+- **Unmet is unmet.** A failing or unchecked obligation is filed and
+  reported as failing or unchecked — never smoothed into "mostly passing" or
+  silently dropped from the report. This is the direct fix for the
+  motivating failure below: findings discovered only by reading data after
+  the fact, never by a test failing loudly in the record.
+- **A partial or failed run is still a valid input.** There is no
+  completion precondition — validate whatever merged, report the rest as
+  not yet checkable.
+- **`llm`-origin filings stay proposed until the user confirms.** Same
+  anti-fabrication contract as every other origin vocabulary in this
+  method — an agent's own proposal never self-confirms.
+- **Provenance both ways.** Every evidence record ties back to an obligation
+  (a claim or an approved deviation); every delta ties back to what it
+  diverges from and forward to the evidence that backs it. An untraceable
+  evidence or delta record is not filed.
+- **This is not a new gate.** Like `/deviate`, `/validate-delivery` does not
+  add a fourth standing human gate — it produces the record `/summarize-
+  delivery` and the final PR review consume; the three gates (spec,
+  implementation split plan, final PR) are unchanged.
+
+## Worked example
+
+Wave 2 of a plan merged the `export --format widget-md` verb. The plan's
+confirmed `success_signal` claim `c9` said "round-tripping a widget through
+`export` and back loses no fields." A behavioral test exists for it,
+marked `@pytest.mark.behavioral`, plus two more behavioral tests for
+adjacent claims — one of which fails.
+
+```bash
+# 1. Identify the obligation (echoes its id, e.g. o1)
+devague oblige c9 --seam "widget export round-trip" \
+  --behavior "round-tripping a widget loses no fields"
+
+# 2. Locate and run the behavioral tests agent-side (read-only)
+pytest -m behavioral -q
+# -> tests/behavioral/test_widget_export.py::test_round_trip PASSED
+# -> tests/behavioral/test_widget_export.py::test_empty_field_rendering FAILED
+
+# 3. File evidence for each outcome — the failure included, not smoothed over
+devague evidence --obligation o1 \
+  --test tests/behavioral/test_widget_export.py::test_round_trip \
+  --behavior "asserts an exported-then-reimported widget compares equal field by field" \
+  --contract "round-tripping a widget loses no fields" \
+  --type automated --strength execution \
+  --basis "behavioral test ran green at the named commit" \
+  --outcome pass --run-commit abc1234 --run-timestamp 2026-08-31T12:00:00
+devague evidence --obligation o2 \
+  --test tests/behavioral/test_widget_export.py::test_empty_field_rendering \
+  --behavior "asserts an absent widget field renders as an empty line" \
+  --contract "an absent field renders honestly, never as filler" \
+  --type automated --strength execution \
+  --basis "behavioral test ran red at the named commit" \
+  --outcome fail --run-commit abc1234 --run-timestamp 2026-08-31T12:00:00
+
+# 4. File a delta if the failure reveals a real behavioral divergence
+devague delta --kind amended \
+  --behavior "empty widget fields render as garbled text, not an empty line" \
+  --caused-by c11 --evidence e2
+
+# 5. Report faithfully: c9 is validated; c11's claimed behavior is unmet —
+#    say so plainly, hand it to /summarize-delivery as Remaining Work, not
+#    as a passing claim.
+```
+
+`/summarize-delivery` then reads these back — `c9`'s Delivery Claims row
+cites evidence `e1` at `high` confidence (a passing behavioral test); `c11`'s
+row is `unverified` or explicitly failing, never rounded up.
+
+## After validating — hand off to /summarize-delivery
+
+Once every obligation in scope has an evidence record (or is reported as not
+yet checkable) and any behavioral deltas are filed, this leg is done — there
+is nothing separate to export, the filed records already live in devague
+state. Continue with the sibling **`/summarize-delivery`** skill: its
+Delivery Claims table reads the evidence and deltas filed here directly
+(`devague summary`), so the confidence a claim carries in the final delivery
+artifact traces back to a test that actually ran, not to memory. Don't stop
+at "tests ran" — the standing flow is **file the evidence, then
+`/summarize-delivery`**.
+
+## The motivating record
+
+The Reasoning Degradation Ledger (`devague lapse`, issue
+[`agentculture/devague#97`](https://github.com/agentculture/devague/issues/97))
+exists because of this, cited verbatim: "Four graders failed in that
+cycle... Every one was found by reading data afterwards; none by a test
+failing." That gap — a corrections record reconstructed only at the end,
+from memory, because nothing forced a behavioral check to run and be filed
+along the way — is exactly what `/validate-delivery` closes for the
+*execution* side, the same way `/challenge` closes it for the *spec* side.
+
+The design itself traces to issue
+[`agentculture/devague#107`](https://github.com/agentculture/devague/issues/107),
+"Suggestion: behavioral validation and a derived current spec," which
+proposed behavior as the primary contract, four evidence types, a strength
+ladder, and the current spec as a projection of a behavior ledger rather
+than a hand-maintained document. This skill is the method-only front door to
+that idea: it does not implement the full ledger or the derived-spec
+projection — it establishes where in the flow behavioral checking happens,
+what gets filed, and how the failure mode #97 documented gets closed instead
+of rediscovered.
+
+## Provenance
+
+This is a **first-party** skill — its origin is `agentculture/devague`, the
+*eighth* in the outbound family after `/scope`, `/think`, `/challenge`,
+`/spec-to-plan`, `/assign-to-workforce`, `/deviate`, and
+`/summarize-delivery`, covering the execution-to-evidence leg that runs
+after a plan's waves merge and before the delivery summary is written.
+guildmaster pulls it from here and broadcasts it to the AgentCulture mesh;
+because devague is upstream, it is **never re-vendored back** from
+guildmaster's re-broadcast copy. The `cite, don't import` policy still
+holds: downstream repos copy it, they don't symlink or depend on it. See
+`docs/skill-sources.md`.

{microduck_cli-0.7.0 → microduck_cli-0.9.0}/.claude/skills.local.yaml.example

@@ -14,3 +14,8 @@ sibling_projects:
   - ../guildmaster
   - ../steward
   - ../teken
+  # Robot-family siblings — the architecture microduck-cli composes.
+  # See CLAUDE.md "The three sibling repos, and what to take from each".
+  - ../neurosymbolic-system
+  - ../reachy-mini-cli
+  - ../arm101-cli

microduck_cli-0.9.0/.devague/current

@@ -0,0 +1 @@
+microduck-cli-env-teach-operate-rules

microduck_cli-0.9.0/.devague/current_plan

@@ -0,0 +1 @@
+microduck-cli-env-teach-operate-rules