重构主控编排与运行时预热链路，统一工作区提示词/专家调度协议并补齐 wiki 记忆注入与写回闭环。

同时收敛启动与运维脚本默认行为（含 wiki worker）、更新 Admin 可观测性与相关测试，降低首轮时延并提高运行稳定性。 Made-with: Cursor
2026-10-18 19:43:22 +08:00 · 2026-04-26 08:34:33 +08:00 · 2026-04-26 08:34:33 +08:00 · dbbe3add6a
commit dbbe3add6a
parent 4a23b715a2
14438 changed files with 2693620 additions and 2546 deletions
--- a/openclaw/.pi/prompts/cl.md
+++ b/openclaw/.pi/prompts/cl.md
@ -0,0 +1,58 @@
+---
+description: Audit changelog entries before release
+---
+
+Audit changelog entries for all commits since the last release.
+
+## Process
+
+1. **Find the last release tag:**
+
+   ```bash
+   git tag --sort=-version:refname | head -1
+   ```
+
+2. **List all commits since that tag:**
+
+   ```bash
+   git log <tag>..HEAD --oneline
+   ```
+
+3. **Read each package's [Unreleased] section:**
+   - packages/ai/CHANGELOG.md
+   - packages/tui/CHANGELOG.md
+   - packages/coding-agent/CHANGELOG.md
+
+4. **For each commit, check:**
+   - Skip: changelog updates, doc-only changes, release housekeeping
+   - Determine which package(s) the commit affects (use `git show <hash> --stat`)
+   - Verify a changelog entry exists in the affected package(s)
+   - For external contributions (PRs), verify format: `Description ([#N](url) by [@user](url))`
+
+5. **Cross-package duplication rule:**
+   Changes in `ai`, `agent` or `tui` that affect end users should be duplicated to `coding-agent` changelog, since coding-agent is the user-facing package that depends on them.
+
+6. **Add New Features section after changelog fixes:**
+   - Insert a `### New Features` section at the start of `## [Unreleased]` in `packages/coding-agent/CHANGELOG.md`.
+   - Propose the top new features to the user for confirmation before writing them.
+   - Link to relevant docs and sections whenever possible.
+
+7. **Report:**
+   - List commits with missing entries
+   - List entries that need cross-package duplication
+   - Add any missing entries directly
+
+## Changelog Format Reference
+
+Sections (in order):
+
+- `### Breaking Changes` - API changes requiring migration
+- `### Added` - New features
+- `### Changed` - Changes to existing functionality
+- `### Fixed` - Bug fixes
+- `### Removed` - Removed features
+
+Attribution:
+
+- Internal: `Fixed foo ([#123](https://github.com/badlogic/pi-mono/issues/123))`
+- External: `Added bar ([#456](https://github.com/badlogic/pi-mono/pull/456) by [@user](https://github.com/user))`
--- a/openclaw/.pi/prompts/is.md
+++ b/openclaw/.pi/prompts/is.md
@ -0,0 +1,22 @@
+---
+description: Analyze GitHub issues (bugs or feature requests)
+---
+
+Analyze GitHub issue(s): $ARGUMENTS
+
+For each issue:
+
+1. Read the issue in full, including all comments and linked issues/PRs.
+
+2. **For bugs**:
+   - Ignore any root cause analysis in the issue (likely wrong)
+   - Read all related code files in full (no truncation)
+   - Trace the code path and identify the actual root cause
+   - Propose a fix
+
+3. **For feature requests**:
+   - Read all related code files in full (no truncation)
+   - Propose the most concise implementation approach
+   - List affected files and changes needed
+
+Do NOT implement unless explicitly asked. Analyze and propose only.
--- a/openclaw/.pi/prompts/landpr.md
+++ b/openclaw/.pi/prompts/landpr.md
@ -0,0 +1,73 @@
+---
+description: Land a PR (merge with proper workflow)
+---
+
+Input
+
+- PR: $1 <number|url>
+  - If missing: use the most recent PR mentioned in the conversation.
+  - If ambiguous: ask.
+
+Do (end-to-end)
+Goal: PR must end in GitHub state = MERGED (never CLOSED). Prefer `gh pr merge --squash`; use `--rebase` only when preserving commit history is required.
+
+1. Assign PR to self:
+   - `gh pr edit <PR> --add-assignee @me`
+2. Repo clean: `git status`.
+3. Identify PR meta (author + head branch):
+
+   ```sh
+   gh pr view <PR> --json number,title,author,headRefName,baseRefName,headRepository --jq '{number,title,author:.author.login,head:.headRefName,base:.baseRefName,headRepo:.headRepository.nameWithOwner}'
+   contrib=$(gh pr view <PR> --json author --jq .author.login)
+   head=$(gh pr view <PR> --json headRefName --jq .headRefName)
+   head_repo_url=$(gh pr view <PR> --json headRepository --jq .headRepository.url)
+   ```
+
+4. Fast-forward base:
+   - `git checkout main`
+   - `git pull --ff-only`
+5. Create temp base branch from main:
+   - `git checkout -b temp/landpr-<ts-or-pr>`
+6. Check out PR branch locally:
+   - `gh pr checkout <PR>`
+7. Rebase PR branch onto temp base:
+   - `git rebase temp/landpr-<ts-or-pr>`
+   - Fix conflicts; keep history tidy.
+8. Fix + tests + changelog:
+   - Implement fixes + add/adjust tests
+   - Update `CHANGELOG.md` and mention `#<PR>` + `@$contrib`
+9. Decide merge strategy:
+   - Squash (preferred): use when we want a single clean commit
+   - Rebase: use only when we explicitly want to preserve commit history
+   - If unclear, ask
+10. Full gate (BEFORE commit):
+    - `pnpm lint && pnpm build && pnpm test`
+11. Commit via committer (final merge commit only includes PR # + thanks):
+    - For the final merge-ready commit: `committer "fix: <summary> (#<PR>) (thanks @$contrib)" CHANGELOG.md <changed files>`
+    - If you need intermediate fix commits before the final merge commit, keep those messages concise and **omit** PR number/thanks.
+    - `land_sha=$(git rev-parse HEAD)`
+12. Push updated PR branch (rebase => usually needs force):
+
+    ```sh
+    git remote add prhead "$head_repo_url.git" 2>/dev/null || git remote set-url prhead "$head_repo_url.git"
+    git push --force-with-lease prhead HEAD:$head
+    ```
+
+13. Merge PR (must show MERGED on GitHub):
+    - Squash (preferred): `gh pr merge <PR> --squash`
+    - Rebase (history-preserving fallback): `gh pr merge <PR> --rebase`
+    - Never `gh pr close` (closing is wrong)
+14. Sync main:
+    - `git checkout main`
+    - `git pull --ff-only`
+15. Comment on PR with what we did + SHAs + thanks:
+
+    ```sh
+    merge_sha=$(gh pr view <PR> --json mergeCommit --jq '.mergeCommit.oid')
+    gh pr comment <PR> --body "Landed via temp rebase onto main.\n\n- Gate: pnpm lint && pnpm build && pnpm test\n- Land commit: $land_sha\n- Merge commit: $merge_sha\n\nThanks @$contrib!"
+    ```
+
+16. Verify PR state == MERGED:
+    - `gh pr view <PR> --json state --jq .state`
+17. Delete temp branch:
+    - `git branch -D temp/landpr-<ts-or-pr>`
--- a/openclaw/.pi/prompts/reviewpr.md
+++ b/openclaw/.pi/prompts/reviewpr.md
@ -0,0 +1,134 @@
+---
+description: Review a PR thoroughly without merging
+---
+
+Input
+
+- PR: $1 <number|url>
+  - If missing: use the most recent PR mentioned in the conversation.
+  - If ambiguous: ask.
+
+Do (review-only)
+Goal: produce a thorough review and a clear recommendation (READY FOR /landpr vs NEEDS WORK vs INVALID CLAIM). Do NOT merge, do NOT push, do NOT make changes in the repo as part of this command.
+
+0. Truthfulness + reality gate (required for bug-fix claims)
+   - Do not trust the issue text or PR summary by default; verify in code and evidence.
+   - If the PR claims to fix a bug linked to an issue, confirm the bug exists now (repro steps, logs, failing test, or clear code-path proof).
+   - Prove root cause with exact location (`path/file.ts:line` + explanation of why behavior is wrong).
+   - Verify fix targets the same code path as the root cause.
+   - Require a regression test when feasible (fails before fix, passes after fix). If not feasible, require explicit justification + manual verification evidence.
+   - Hallucination/BS red flags (treat as BLOCKER until disproven):
+     - claimed behavior not present in repo,
+     - issue/PR says "fixes #..." but changed files do not touch implicated path,
+     - only docs/comments changed for a runtime bug claim,
+     - vague AI-generated rationale without concrete evidence.
+
+1. Identify PR meta + context
+
+   ```sh
+   gh pr view <PR> --json number,title,state,isDraft,author,baseRefName,headRefName,headRepository,url,body,labels,assignees,reviewRequests,files,additions,deletions --jq '{number,title,url,state,isDraft,author:.author.login,base:.baseRefName,head:.headRefName,headRepo:.headRepository.nameWithOwner,additions,deletions,files:.files|length}'
+   ```
+
+2. Read the PR description carefully
+   - Summarize the stated goal, scope, and any "why now?" rationale.
+   - Call out any missing context: motivation, alternatives considered, rollout/compat notes, risk.
+
+3. Read the diff thoroughly (prefer full diff)
+
+   ```sh
+   gh pr diff <PR>
+   # If you need more surrounding context for files:
+   gh pr checkout <PR>   # optional; still review-only
+   git show --stat
+   ```
+
+4. Validate the change is needed / valuable
+   - What user/customer/dev pain does this solve?
+   - Is this change the smallest reasonable fix?
+   - Are we introducing complexity for marginal benefit?
+   - Are we changing behavior/contract in a way that needs docs or a release note?
+
+5. Evaluate implementation quality + optimality
+   - Correctness: edge cases, error handling, null/undefined, concurrency, ordering.
+   - Design: is the abstraction/architecture appropriate or over/under-engineered?
+   - Performance: hot paths, allocations, queries, network, N+1s, caching.
+   - Security/privacy: authz/authn, input validation, secrets, logging PII.
+   - Backwards compatibility: public APIs, config, migrations.
+   - Style consistency: formatting, naming, patterns used elsewhere.
+
+6. Tests & verification
+   - Identify what's covered by tests (unit/integration/e2e).
+   - Are there regression tests for the bug fixed / scenario added?
+   - Missing tests? Call out exact cases that should be added.
+   - If tests are present, do they actually assert the important behavior (not just snapshots / happy path)?
+
+7. Follow-up refactors / cleanup suggestions
+   - Any code that should be simplified before merge?
+   - Any TODOs that should be tickets vs addressed now?
+   - Any deprecations, docs, types, or lint rules we should adjust?
+
+8. Key questions to answer explicitly
+   - Is the core claim substantiated by evidence, or is it likely invalid/hallucinated?
+   - Can we fix everything ourselves in a follow-up, or does the contributor need to update this PR?
+   - Any blocking concerns (must-fix before merge)?
+   - Is this PR ready to land, or does it need work?
+
+9. Output (structured)
+   Produce a review with these sections:
+
+A) TL;DR recommendation
+
+- One of: READY FOR /landpr | NEEDS WORK | INVALID CLAIM (issue/bug not substantiated) | NEEDS DISCUSSION
+- 1–3 sentence rationale.
+
+B) Claim verification matrix (required)
+
+- Fill this table:
+
+  | Field                                           | Evidence |
+  | ----------------------------------------------- | -------- |
+  | Claimed problem                                 | ...      |
+  | Evidence observed (repro/log/test/code)         | ...      |
+  | Root cause location (`path:line`)               | ...      |
+  | Why this fix addresses that root cause          | ...      |
+  | Regression coverage (test name or manual proof) | ...      |
+
+- If any row is missing/weak, default to `NEEDS WORK` or `INVALID CLAIM`.
+
+C) What changed
+
+- Brief bullet summary of the diff/behavioral changes.
+
+D) What's good
+
+- Bullets: correctness, simplicity, tests, docs, ergonomics, etc.
+
+E) Concerns / questions (actionable)
+
+- Numbered list.
+- Mark each item as:
+  - BLOCKER (must fix before merge)
+  - IMPORTANT (should fix before merge)
+  - NIT (optional)
+- For each: point to the file/area and propose a concrete fix or alternative.
+- If evidence for the core bug claim is missing, add a `BLOCKER` explicitly.
+
+F) Tests
+
+- What exists.
+- What's missing (specific scenarios).
+- State clearly whether there is a regression test for the claimed bug.
+
+G) Follow-ups (optional)
+
+- Non-blocking refactors/tickets to open later.
+
+H) Suggested PR comment (optional)
+
+- Offer: "Want me to draft a PR comment to the author?"
+- If yes, provide a ready-to-paste comment summarizing the above, with clear asks.
+
+Rules / Guardrails
+
+- Review only: do not merge (`gh pr merge`), do not push branches, do not edit code.
+- If you need clarification, ask questions rather than guessing.