NiuBlibing · NiuBlibing · May 10, 2026 · May 10, 2026 · May 10, 2026 · May 10, 2026
diff --git a/.actrc b/.actrc
@@ -0,0 +1,21 @@
+# act defaults — keeps `act` runs reproducible without flag soup.
+# https://github.com/nektos/act
+
+# Map the ARM runner used in production to a standard amd64 image so act
+# can run it on any host. (Prod still uses ubuntu-24.04-arm via GitHub.)
+-P ubuntu-24.04-arm=catthehacker/ubuntu:act-latest
+-P ubuntu-latest=catthehacker/ubuntu:act-latest
+
+# Load secrets (e.g. ANTHROPIC_API_KEY) from a local file. Create it as:
+#   ANTHROPIC_API_KEY=sk-ant-...
+# .secrets is gitignored.
+--secret-file .secrets
+
+# Force amd64 container architecture (Apple Silicon hosts otherwise pull
+# arm64 images that lack many tools).
+--container-architecture linux/amd64
+
+# Run a local artifact server so actions/upload-artifact and
+# actions/download-artifact work between jobs. The directory is
+# auto-created by scripts/dev/act-local.sh on first run.
+--artifact-server-path /tmp/act-artifacts
diff --git a/.cargo/audit.toml b/.cargo/audit.toml
@@ -3,11 +3,9 @@
 
 [advisories]
 ignore = [
-    # wasmtime vulns via extism — no upstream fix available; plugins feature-gated
     "RUSTSEC-2026-0006",  # wasmtime f64.copysign segfault on x86-64
     "RUSTSEC-2026-0020",  # WASI guest-controlled resource exhaustion
     "RUSTSEC-2026-0021",  # WASI http fields panic
-    # wasmtime 2026-04-09 batch — extism 1.21.0 pins wasmtime 41.x; no extism release with fix yet
     "RUSTSEC-2026-0085",  # panic when lifting `flags` component value
     "RUSTSEC-2026-0086",  # host data leakage with 64-bit tables and Winch
     "RUSTSEC-2026-0087",  # f64x2.splat Cranelift x86-64 segfault
@@ -19,9 +17,7 @@ ignore = [
     "RUSTSEC-2026-0094",  # Winch table.grow improperly masked return value
     "RUSTSEC-2026-0095",  # Winch sandbox-escape (critical)
     "RUSTSEC-2026-0096",  # aarch64 Cranelift sandbox-escape (critical)
-    # instant crate unmaintained — transitive dep via nostr; no upstream fix
     "RUSTSEC-2024-0384",
-    # rustls-webpki via rumqttc 0.25.1 — rumqttc pins rustls-webpki ^0.102; no upstream release with fix
     "RUSTSEC-2026-0049",  # CRL matching bypass
     "RUSTSEC-2026-0098",  # URI name constraint incorrectly accepted (2026-04-14)
     "RUSTSEC-2026-0099",  # URI name constraint incorrectly accepted (2026-04-14)

diff --git a/.cargo/config.toml b/.cargo/config.toml
@@ -1,3 +1,11 @@
+[alias]
+mdbook = "run --release -p xtask --bin mdbook --"
+fluent = "run --release -p xtask --bin fluent --"
+web = "run --release -p xtask --bin web --"
+
+[build]
+rustdocflags = ["--default-theme=ayu"]
+
 [target.x86_64-unknown-linux-musl]
 rustflags = ["-C", "link-arg=-static"]
 

diff --git a/.claude/skills/changelog-generation/SKILL.md b/.claude/skills/changelog-generation/SKILL.md
@@ -15,7 +15,7 @@ checked out and up to date.
 
 Read the protocol reference before doing anything else:
 
-- `docs/contributing/changelog-generation.md` — **the full procedure**; follow it
+- `docs/book/src/maintainers/changelog-generation.md` — **the full procedure**; follow it
   exactly for every run. It defines the commit range logic, categorisation rules,
   GraphQL contributor resolution, filter lists, output format, and release workflow
   integration.
@@ -130,7 +130,7 @@ to `master` directly.
 
 ## Execution rules
 
-1. **Always read `docs/contributing/changelog-generation.md` first.** The protocol
+1. **Always read `docs/book/src/maintainers/changelog-generation.md` first.** The protocol
    file is authoritative. If anything in this skill conflicts with it, the protocol
    wins.
 2. **Always report the resolved range before doing any work.** The user should
@@ -147,5 +147,6 @@ to `master` directly.
 7. **Always confirm before committing.** Show the user the exact commit message
    and ask for an explicit yes. Do not infer consent from prior steps.
 8. **Never push to `master` directly.** Always push to the open release PR branch.
-9. **Never delete `CHANGELOG-next.md` manually.** The release workflow deletes it
-   automatically after a successful stable release.
+9. **Do not delete `CHANGELOG-next.md` manually.** The file is intentionally left on
+   `master` between releases and is overwritten at the start of the next release cycle.
+   No cleanup is needed after a release ships.
diff --git a/.claude/skills/github-issue-triage/SKILL.md b/.claude/skills/github-issue-triage/SKILL.md
@@ -12,13 +12,13 @@ You are an autonomous issue triage and lifecycle agent for ZeroClaw. You triage,
 Read these repository files at the start of every session — they are authoritative and override this skill if conflicts exist:
 
 - `AGENTS.md` — conventions, risk tiers, anti-patterns, core engineering constraints
-- `docs/contributing/reviewer-playbook.md` — §4 Issue Triage and Backlog Governance
-- `docs/contributing/pr-workflow.md` — §8.3–8.4 Issue triage discipline and automation guards
-- `docs/contributing/pr-discipline.md` — privacy rules, neutral wording requirements
+- `docs/book/src/maintainers/reviewer-playbook.md` — Issue Triage section
+- `docs/book/src/maintainers/pr-workflow.md` — Review SLA and queue discipline
+- `docs/book/src/contributing/privacy.md` — privacy rules, neutral wording requirements
 
 Then read `references/triage-protocol.md` for the full mode-by-mode workflow.
 
-The protocol encodes operational details from RFC #5577 (governance, stale policy, label taxonomy) and RFC #5615 (contribution culture). If you need background context beyond what the protocol provides, fetch these RFCs (open issues in zeroclaw-labs/zeroclaw). The RFCs are authoritative where they conflict with this skill — but the protocol already reflects their current state, so routine sessions should not need to fetch them.
+The protocol encodes operational details from RFC #5577 (governance and stale thresholds), RFC #5615 (contribution culture), and later maintainer label-policy corrections. If you need background context beyond what the protocol provides, fetch those RFCs or the current maintainer label guide. RFC #5577 remains authoritative for stale timing; `docs/book/src/maintainers/labels.md` and `references/triage-protocol.md` carry the current operational label policy.
 
 ## Invocation
 
@@ -50,7 +50,7 @@ The protocol encodes operational details from RFC #5577 (governance, stale polic
 | Action | Authority | Condition |
 |---|---|---|
 | Apply labels | Act | Always |
-| Remove labels | Act | Only for labels the agent applied in this session, or `status:stale` when the author has re-engaged. Never remove `no-stale`, `priority:critical`, `status:blocked`, or `type:rfc` — these are protection labels. |
+| Remove labels | Act | Only for labels the agent applied in this session, or `status:stale` when the author has re-engaged. Never remove `status:no-stale`, `priority:p0`, or `type:rfc` autonomously. Do not remove `status:blocked` during routine triage; during a stale pass, first verify the recorded blocker and present any proposed `status:blocked` change to the user. |
 | Comment on an issue | Act | Always |
 | Close — fixed by merged PR | Act (single-issue: present first) | PR confirmed merged; issue explicitly referenced in PR |
 | Close — duplicate | Act (single-issue: present first) | Concrete shared identifier confirmed per §3 Pass 2; primary issue clearly identified |
@@ -83,7 +83,7 @@ Every comment must be:
 - **Specific to the issue** — never a copy-paste that could apply to anything
 - **Referenced** — links at least one other issue, PR, or specific docs section so the reporter has somewhere to go next
 - **Welcoming** — the repo is under new management with a human touch; do not discourage contributors; assume good faith
-- **Privacy-compliant** — the `docs/contributing/pr-discipline.md` privacy rules apply to code, tests, fixtures, and examples (use `zeroclaw_user`, `example.com`, etc.). In issue comments, addressing contributors by their GitHub handle (@username) is expected and welcome — that's how you talk to people on GitHub. Do not put real names, emails, or personal data in comments, but @-mentioning the issue author is not a privacy violation.
+- **Privacy-compliant** — the `docs/book/src/contributing/privacy.md` rules apply to code, tests, fixtures, and examples (use `zeroclaw_user`, `example.com`, etc.). In issue comments, addressing contributors by their GitHub handle (@username) is expected and welcome — that's how you talk to people on GitHub. Do not put real names, emails, or personal data in comments, but @-mentioning the issue author is not a privacy violation.
 - **Concise** — under ~200 words for routine actions; longer only when the issue warrants real explanation
 
 Situational tailoring is always preferred. If multiple issues in a batch warrant structurally similar comments (e.g., a stale sweep), generate the shared pattern at runtime and vary it per issue — do not apply a literal copy-paste to more than one issue.