15c30f1fbe
Some checks are pending
CI / lint-and-test (push) Waiting to run
* make Leo skill onboarding clean-context reproducible * harden Leo clean-context skill acceptance
87 lines
3 KiB
Markdown
87 lines
3 KiB
Markdown
---
|
|
name: leo-telegram-canary-ops
|
|
description: Use for live Leo Telegram tests through authenticated Chrome/Computer Use, including memory, KB audit, staged DB writes, screenshots, and clear separation from external outreach.
|
|
---
|
|
|
|
# Leo Telegram Canary Ops
|
|
|
|
## Job
|
|
|
|
Run Telegram-visible Leo canaries when testing Leo itself, with retained screenshots and DB readbacks.
|
|
|
|
## Trigger Phrases
|
|
|
|
- "test Leo in Telegram"
|
|
- "send the Leo group message"
|
|
- "Telegram-visible proof"
|
|
- "Chrome Telegram canary"
|
|
- "Leo remembers conversation"
|
|
- "staged write through Telegram"
|
|
|
|
## Authorization Boundary
|
|
|
|
Live Telegram bot messages to the Leo group are authorized when they are test canaries for Leo behavior.
|
|
|
|
This is different from external outreach. Do not send external outreach, partner messages, public announcements, or non-test communications without exact authorization.
|
|
|
|
## Required Tooling
|
|
|
|
Use Computer Use through `node_repl` and the Chrome/Computer Use skill path. Do not use:
|
|
|
|
- AppleScript,
|
|
- `osascript`,
|
|
- JXA,
|
|
- System Events,
|
|
- focus hijacking,
|
|
- foregrounding hacks.
|
|
|
|
## Canary Types
|
|
|
|
Name the canary before sending:
|
|
|
|
- bot readiness,
|
|
- memory,
|
|
- KB audit truth,
|
|
- proposed-vs-applied truth,
|
|
- open-ended m3taversal-style triage,
|
|
- staged write,
|
|
- no-canonical-mutation proof,
|
|
- screenshot/readback proof.
|
|
|
|
## Message Discipline
|
|
|
|
Use unique markers such as `WL-LIVE-TG-M3TAVERSAL-YYYYMMDD-Tn`.
|
|
|
|
Ask Leo for machine-checkable reply markers like:
|
|
|
|
- `LIVE_TG_TURN1_ACK`
|
|
- `LIVE_TG_TURN3_STAGED`
|
|
- `LIVE_TG_TURN4_READBACK`
|
|
|
|
Do not rely only on exact-ID prompts. At least one representative canary should be a vague operator-style prompt such as: m3taversal says the agents are not working, the KB is in the same state as last night, and Leo should be able to manipulate the KB; ask Leo what that means, what it would inspect first, what fixed means, and how it separates proposed, approved, and applied. Keep this canary read-only unless the task explicitly authorizes a staging or apply step.
|
|
|
|
## Required Proof
|
|
|
|
After each live Telegram canary:
|
|
|
|
1. Capture screenshot.
|
|
2. Record exact message sent.
|
|
3. Record Leo reply marker and substance.
|
|
4. Query DB if the canary involves DB state.
|
|
5. Record canonical public table counts when proving no mutation.
|
|
6. Save a local markdown/json artifact.
|
|
7. Sync artifacts to VPS report dir when relevant.
|
|
|
|
## Current Known Proof
|
|
|
|
- Live memory and KB audit are retained in
|
|
`docs/reports/leo-working-state-20260709/telegram-live-canary-current.json`.
|
|
- Live staged-write proof is retained in
|
|
`docs/reports/leo-working-state-20260709/telegram-live-db-write-canary-20260709.json`.
|
|
- Open-ended m3taversal-standard read-only triage is retained in
|
|
`docs/reports/leo-working-state-20260709/telegram-live-open-ended-suite-current.md`.
|
|
|
|
Historical receipts contain immutable legacy marker IDs. Treat them only as
|
|
evidence identifiers; never reuse them as a participant name or future marker.
|
|
|
|
Use `docs/reports/leo-working-state-20260709/current-truth-index.md` for artifact paths.
|