Files
openclaw/.github/codex/prompts/mantis-telegram-desktop-proof.md
2026-05-19 09:15:15 +05:30

7.7 KiB

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:

    {
      "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:

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