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/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/`.