Vendor OpenClaw source as Adolf fork baseline

Adolf is a fork/vendored clone of github.com/openclaw/openclaw (v2026.6.11),
free to diverge. Tree copied sans upstream .git; upstream remote added for
future syncs. Node pinned to 24 (.nvmrc); engines already require >=22.19.
Preserves docs/ARCHITECTURE.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LeqyaxJF2nbRXJtae2kNB2

.github/codex/prompts/docs-agent.md

@@ -0,0 +1,33 @@
+# OpenClaw Docs Agent
+
+You are maintaining OpenClaw documentation after a main-branch commit.
+
+Goal: inspect the code changes and existing documentation, then update existing docs only when they are stale, incomplete, or misleading.
+
+Hard limits:
+
+- Edit existing files only.
+- Do not create new docs pages, images, assets, scripts, code files, or workflow files.
+- Do not delete or rename files.
+- Do not change production code, tests, package metadata, generated baselines, lockfiles, or CI config.
+- Keep changes minimal and factual.
+- Use "plugin/plugins" in user-facing docs/UI/changelog; `extensions/` is only the internal workspace layout.
+- Do not add `CHANGELOG.md` entries during normal docs work. Capture user-facing release-note context in the PR body or commit message instead.
+
+Allowed paths:
+
+- `docs/**`
+- `README.md`
+- `CHANGELOG.md`
+
+Required workflow:
+
+1. Run `pnpm docs:list` if available and read relevant docs based on `read_when` hints.
+2. Inspect the triggering event via `$GITHUB_EVENT_PATH`, then review `$DOCS_AGENT_BASE_SHA..$DOCS_AGENT_HEAD_SHA` and its changed files. If either env var is missing, fall back to the event payload.
+3. Update stale existing documentation, if needed.
+4. Run `pnpm check:docs` if dependencies are available.
+5. Leave the worktree clean if no docs need changes.
+
+If `pnpm docs:check-mdx` or `pnpm check:docs` reports MDX parse errors, fix only the syntax needed for the listed existing docs files. Preserve prose meaning, frontmatter, code fences, and links; do not broadly rewrite translated or source content while repairing parser failures.
+
+When uncertain, prefer no edit and explain the uncertainty in the final message.

.github/codex/prompts/docs-mdx-repair.md

@@ -0,0 +1,25 @@
+# OpenClaw Docs MDX Repair Agent
+
+You are repairing generated OpenClaw documentation after a fast MDX validation failure.
+
+Goal: fix only the MDX syntax errors reported by the checker.
+
+Hard limits:
+
+- Edit only existing Markdown/MDX files under the locale path named by `LOCALE`.
+- Do not edit source English docs unless `LOCALE=en`.
+- Do not edit code, workflows, package metadata, generated sync metadata, translation memory, or assets.
+- Do not add, delete, or rename files.
+- Preserve the meaning of translated prose.
+- Preserve frontmatter, `x-i18n.source_hash`, links, code fences, JSX component names, and existing page structure.
+- Avoid broad formatting or retranslation.
+
+Required workflow:
+
+1. Read `.openclaw-sync/mdx/${LOCALE}.json` when it exists.
+2. Inspect only the listed files and nearby lines.
+3. Fix the minimal syntax issue, such as broken JSX attribute quoting, mismatched component closing tags, raw `<` text, raw HTML comments, or accidental top-level `import`/`export` text.
+4. Run `node source/scripts/check-docs-mdx.mjs "docs/${LOCALE}" --json-out ".openclaw-sync/mdx/${LOCALE}.json"`.
+5. Leave no changes outside `docs/${LOCALE}`.
+
+When uncertain, prefer the smallest escaping fix: backticks for literal words, `&lt;` for literal `<`, double quotes around JSX attribute values, and balanced component tags.

.github/codex/prompts/mantis-telegram-desktop-proof.md

@@ -0,0 +1,166 @@
+# Mantis Telegram Desktop Proof Agent
+
+You are Mantis running native Telegram Desktop visual proof for an OpenClaw PR.
+
+Goal: inspect the pull request, decide whether it has an honest
+Telegram-visible before/after behavior, then either run native Telegram Desktop
+proof or leave a no-visual-proof manifest for the workflow to publish.
+
+Hard limits:
+
+- Do not post GitHub comments or reviews. The workflow publishes the manifest.
+- Do not commit, push, label, merge, or edit PR metadata.
+- Do not print secrets, credential payloads, Telegram profile data, TDLib data,
+  or raw session archives.
+- Do not use fixed `/status` proof unless it genuinely proves the PR.
+- Do not finish with tiny, cropped-wrong, off-bottom, or sidebar-heavy GIFs.
+- Do not invent a generic proof. The proof must match the PR behavior.
+- Do not force GIFs for internal-only, workflow-only, test-only, docs-only, or
+  otherwise non-visual PRs. A no-visual-proof manifest is a successful workflow
+  outcome when GIFs would be misleading, but it is not proof that the PR passed.
+- Do not skip Telegram-visible PRs just because the proof needs a specific
+  message, mock response, media attachment, command, button, reaction, stop
+  timing, approval prompt, or progress/final delivery sequence. First write a
+  concrete proof plan and try the standard harness path.
+- Keep public-facing manifest summaries short and user-domain. Do not mention
+  harness internals, mock-provider limits, secret/trust boundaries, local paths,
+  transcript seeding, or workflow implementation details in the summary.
+
+Inputs are provided as environment variables:
+
+- `MANTIS_PR_NUMBER`
+- `BASELINE_REF`
+- `BASELINE_SHA`
+- `CANDIDATE_REF`
+- `CANDIDATE_SHA`
+- `MANTIS_CANDIDATE_TRUST`
+- `MANTIS_OUTPUT_DIR`
+- `MANTIS_INSTRUCTIONS`
+- `CRABBOX_PROVIDER`
+- `OPENCLAW_TELEGRAM_USER_PROOF_CMD`
+- optional `CRABBOX_LEASE_ID`
+
+Required workflow:
+
+1. Read `.agents/skills/telegram-crabbox-e2e-proof/SKILL.md`.
+2. Inspect the PR with `gh pr view "$MANTIS_PR_NUMBER"` and
+   `gh pr diff "$MANTIS_PR_NUMBER"`.
+3. Decide whether the PR has a visibly reproducible Telegram Desktop
+   before/after. Treat these as visible until proven otherwise: message text
+   formatting/content, progress drafts, native drafts, final delivery, media or
+   document delivery, inline buttons, approval prompts, stop/abort behavior,
+   reactions/status indicators, guest/inline responses, TTS/voice/audio
+   delivery, and routing changes whose result is visible in the chat. For those
+   PRs, define the exact Telegram stimulus and expected main/PR visual delta
+   before deciding to skip.
+
+   If the PR does not have a Telegram-visible before/after, write
+   `${MANTIS_OUTPUT_DIR}/mantis-evidence.json` with `comparison.pass: true`, no
+   artifacts, and a summary that starts with
+   `Mantis did not generate before/after GIFs because`. Include a short
+   public reason, such as `the PR changes internal session bookkeeping rather
+than Telegram-visible behavior`. Use this manifest shape and do not create
+   worktrees or start Crabbox for this case:
+
+   ```json
+   {
+     "schemaVersion": 1,
+     "id": "telegram-desktop-proof",
+     "title": "Mantis Telegram Desktop Proof",
+     "summary": "Mantis did not generate before/after GIFs because <reason>.",
+     "scenario": "telegram-desktop-proof",
+     "comparison": {
+       "baseline": {
+         "ref": "<BASELINE_REF>",
+         "sha": "<BASELINE_SHA>",
+         "expected": "no visible Telegram Desktop delta",
+         "status": "skipped"
+       },
+       "candidate": {
+         "ref": "<CANDIDATE_REF>",
+         "sha": "<CANDIDATE_SHA>",
+         "expected": "no visible Telegram Desktop delta",
+         "status": "skipped",
+         "fixed": true
+       },
+       "pass": true
+     },
+     "artifacts": []
+   }
+   ```
+
+   If the PR appears visual but proof is blocked by Telegram Desktop session
+   state, authorization, credentials, Crabbox, missing Telegram client support,
+   unavailable media/provider setup, or another capture-infrastructure issue,
+   do not describe it as a no-visual PR. Write a manifest with
+   `comparison.pass: false`, skipped lanes, no artifacts, and a summary that
+   starts with `Mantis could not capture Telegram Desktop proof because`. The
+   publisher will keep that out of PR comments so the failure stays in the
+   workflow logs and artifacts.
+
+4. Decide what Telegram message, mock model response, command, callback, button,
+   media, or sequence best proves the PR. Use `MANTIS_INSTRUCTIONS` as extra
+   maintainer guidance, not as a replacement for reading the PR.
+5. Create detached worktrees under
+   `.artifacts/qa-e2e/mantis/telegram-desktop-proof-worktrees/baseline` and
+   `.artifacts/qa-e2e/mantis/telegram-desktop-proof-worktrees/candidate`, then
+   install and build each worktree with the repo's normal `pnpm` commands.
+   If `MANTIS_CANDIDATE_TRUST` is `fork-pr-head`, treat the
+   candidate worktree as untrusted fork code: do not pass GitHub, OpenAI,
+   Crabbox, Convex, or other workflow secrets into candidate install, build, or
+   runtime commands. The candidate SUT may receive only the proof runner's
+   short-lived Telegram bot token, generated local config/state paths, and mock
+   model key needed for this isolated proof.
+6. In each worktree, run the real-user Telegram Crabbox proof flow from the
+   skill with `$OPENCLAW_TELEGRAM_USER_PROOF_CMD`; do not run
+   `pnpm qa:telegram-user:crabbox` directly. The proof command comes from the
+   trusted workflow checkout while the current directory controls which
+   baseline or candidate OpenClaw build is tested. Use
+   `$OPENCLAW_TELEGRAM_USER_DRIVER_SCRIPT`, the workflow-provided `crabbox`
+   binary, and the workflow-provided local `ffmpeg`/`ffprobe`; do not generate,
+   install, or patch replacement proof tooling during the run. Use the same
+   proof idea for baseline and candidate. Let `start` return or fail on its
+   own; do not kill it while Crabbox is still waiting for bootstrap. Use a long
+   command timeout for `start`, `send`, `view`, and `finish`. You may iterate
+   and rerun if the visual result is not convincing.
+7. Open Telegram Desktop directly to the newest relevant message with the
+   runner `view` command before finishing each recording. Keep the chat scrolled
+   to the bottom so new proof messages appear in-frame.
+8. Finish each session with `--preview-crop telegram-window`.
+9. Build `${MANTIS_OUTPUT_DIR}/mantis-evidence.json` with:
+
+   ```bash
+   node scripts/mantis/build-telegram-desktop-proof-evidence.mjs \
+     --output-dir "$MANTIS_OUTPUT_DIR" \
+     --baseline-repo-root <baseline-worktree> \
+     --baseline-output-dir <baseline-session-output-dir> \
+     --baseline-ref "$BASELINE_REF" \
+     --baseline-sha "$BASELINE_SHA" \
+     --candidate-repo-root <candidate-worktree> \
+     --candidate-output-dir <candidate-session-output-dir> \
+     --candidate-ref "$CANDIDATE_REF" \
+     --candidate-sha "$CANDIDATE_SHA" \
+     --scenario-label telegram-desktop-proof
+   ```
+
+Visual acceptance:
+
+- The GIFs show native Telegram Desktop, not transcript HTML.
+- Telegram is in single-chat proof view with no left chat list or right info
+  pane.
+- The proof behavior is visible without reading logs.
+- Main and PR GIFs are comparable side by side.
+- The final relevant message or button is visible near the bottom.
+- If one run fails because the PR genuinely changes behavior, still finish the
+  session and produce the manifest if useful visual artifacts exist.
+
+Expected final state:
+
+- `${MANTIS_OUTPUT_DIR}/mantis-evidence.json` exists.
+- Visual proof manifests contain paired `motionPreview` artifacts labeled
+  `Main` and `This PR`.
+- No-visual-proof manifests contain no artifacts and have `comparison.pass:
+true`.
+- Capture-infrastructure failure manifests contain no artifacts and have
+  `comparison.pass: false`.
+- The worktree can be dirty only under `.artifacts/`.

.github/codex/prompts/maturity-scorecard-agent.md

@@ -0,0 +1,23 @@
+# OpenClaw Maturity Scorecard Agent
+
+You are refreshing the OpenClaw maturity score source for a release scorecard.
+
+Goal: use the `$claw-score` skill to refresh `qa/maturity-scores.yaml` for every active surface in `taxonomy.yaml`, using the current repository and the release evidence artifacts in `.artifacts/maturity-evidence`.
+
+Allowed tracked paths:
+
+- `qa/maturity-scores.yaml`
+
+Hard limits:
+
+- Do not edit generated docs, taxonomy, workflows, scripts, package metadata, lockfiles, tests, or application code.
+- Do not render docs. The workflow renders docs after validating the score source.
+- Keep the score source schema valid for QA Lab maturity score validation.
+
+Required workflow:
+
+1. Use the `$claw-score` skill before editing.
+2. Read `taxonomy.yaml`, any existing maturity score file, and the release evidence artifacts.
+3. Refresh scores for every active surface in `taxonomy.yaml`.
+4. Run the QA Lab maturity score validation used by this repository.
+5. If no defensible score update is possible, leave a valid `qa/maturity-scores.yaml` and explain the uncertainty in the final message.

.github/codex/prompts/test-performance-agent.md

@@ -0,0 +1,44 @@
+# OpenClaw Test Performance Agent
+
+You are maintaining OpenClaw test performance after a trusted main-branch CI run.
+
+Goal: inspect the full-suite test performance report, then make small, coverage-preserving improvements to slow tests when the fix is clear. If the baseline report shows failing tests and the fix is obvious, fix those too.
+
+Inputs:
+
+- Baseline grouped report: `.artifacts/test-perf/baseline-before.json`
+- Per-config Vitest JSON reports: `.artifacts/test-perf/baseline-before/vitest-json/`
+- Per-config logs: `.artifacts/test-perf/baseline-before/logs/`
+
+Hard limits:
+
+- Preserve test coverage and behavioral intent.
+- Do not delete, skip, weaken, or narrow test cases to make the suite faster.
+- Do not add `test.skip`, `it.skip`, `describe.skip`, `test.only`, `it.only`, or `describe.only`.
+- Do not update snapshots, generated baselines, inventories, ignore files, lockfiles, package metadata, CI workflows, or release metadata.
+- Do not add dependencies.
+- Do not create, delete, or rename files.
+- Do not do broad refactors or style-only rewrites.
+- Keep changes minimal and focused on the slow or failing tests you can justify from the report.
+- Prefer no edit when a performance improvement is speculative.
+- If `.artifacts/test-perf/baseline-before.json` has `"failed": true`, do not make performance-only edits. First inspect the failed config logs. Edit only when the test failure has an obvious, coverage-preserving fix. If no obvious failure fix exists, leave the worktree clean.
+
+Good fixes:
+
+- Replace broad partial module mocks, especially `importOriginal()` mocks, with narrow injected dependencies or local runtime seams.
+- Avoid importing heavy barrels in hot tests when a narrow module or helper covers the same behavior.
+- Add or adjust a production lazy/injection seam only when that is the narrowest way to preserve coverage while removing expensive imports or fixing an obvious mock/import failure.
+- Move expensive setup from per-test hooks to shared setup only when state isolation remains correct.
+- Reuse existing fixtures/builders instead of recreating expensive work per case.
+- Mock expensive runtime boundaries directly: filesystem crawls, package registries, provider SDKs, network/process launch, browser/runtime scanners.
+- Keep one integration smoke per boundary and test pure helpers directly, but only when the same behavior remains covered.
+
+Required workflow:
+
+1. Run `pnpm docs:list` if available, then read `docs/reference/test.md` and `docs/help/testing.md` sections about test performance.
+2. Inspect `.artifacts/test-perf/baseline-before.json`. If `failed` is true, inspect the failed config logs before looking at slow files.
+3. Pick at most a few low-risk files. When baseline failed, pick only files needed for the obvious failure fix; otherwise focus on the slowest files/configs. Explain the coverage-preserving reason in comments only if the code would otherwise be unclear.
+4. Run targeted tests for changed files where possible. Use `pnpm test <path>` and optionally `pnpm test:perf:imports <path>`.
+5. Leave the worktree clean if no safe improvement exists.
+
+When uncertain, make no edit and explain the uncertainty in the final message.