Ray Delivery Diagnosis

Automates delivery lane scans every 4 hours to detect failures, classify issues, update recovery tickets, and attempt specified recovery actions.

Security Scan

The skill's purpose (automated delivery-lane diagnosis and recovery) is plausible, but the runtime instructions rely on running many local Node scripts and reading/writing local config and ticket files while declaring no required binaries, env vars, or install steps — an inconsistency that deserves caution before installing.

Purpose & Capability

The name/description match the instructions (it is a delivery diagnosis and recovery runbook). However, the SKILL.md repeatedly instructs running Node scripts (e.g., node scripts/tony-blog-publish.mjs, postiz-publish.mjs, facebook-poster.mjs) and accessing local workspaces (e.g., ~/.openclaw/workspace-jenny/.env, mission-control/data/). Despite this, the skill metadata lists no required binaries (node) or environment variables. That mismatch (runs Node but doesn't declare node as required) is an incoherence requiring clarification.

Instruction Scope

Instructions explicitly tell the agent to read and update many local paths (mission-control data, recovery tickets, workspace dotfiles) and to execute platform-publishing scripts that could interact with external services and potentially transmit content. The steps stay within the stated domain (delivery lanes), but they grant broad discretion to run arbitrary local Node scripts and modify persistent ticket files — which is a meaningful scope expansion relative to the minimal metadata provided. The SKILL.md also instructs checking ~/.openclaw/workspace-jenny/.env (a user config file), which is sensitive and is not declared in the skill requirements.

Install Mechanism

This is instruction-only with no install spec and no code files shipped. That minimizes the surface from the skill bundle itself (nothing is downloaded or written by installer). The higher risk is runtime: the agent is instructed to execute local scripts that are expected to exist in the runtime environment.

Credentials

The skill declares no required env vars or primary credentials, yet the instructions expect credentials/config to exist (Facebook/X auth, Supabase URL in ~/.openclaw/workspace-jenny/.env, mission-control ticket write access). Recovery actions will likely require API keys or browser auth. The absence of declared required credentials is disproportionate and obscures what secrets the skill actually needs at runtime.

Persistence & Privilege

always is false and the skill is not requesting any special platform persistence or modification of other skills. It writes/updates local mission-control/recovery ticket files as part of its purpose, which is expected behavior for a recovery runner. No cross-skill or system-wide configuration changes are instructed.

What to consider before installing

This skill appears to be a runbook that will run local Node scripts and modify mission-control/recovery-ticket files. Before installing or enabling it: 1) Confirm that the runtime environment actually contains the referenced scripts and that you trust their contents — ask for the script sources or inspect them in a safe environment. 2) Verify Node is available and consider declaring it as a required binary. 3) Determine what credentials are needed (Facebook/X tokens, Supabase URL, any posting API keys) and provide them only with least privilege; the skill does not declare these. 4) Run initially in a sandbox/test environment and use dry-run flags as suggested; review the outputs it would write to mission-control and recovery tickets. 5) If you cannot inspect the referenced scripts, treat the skill as untrusted: it could run arbitrary code that reads local dotfiles (~/.openclaw), writes ticket files, or transmits data. 6) Ask the publisher for provenance (source repository, maintainers) and for explicit declarations of required binaries and credentials before using it in production.

Purpose

Recovery ticket runner and delivery diagnosis agent. Runs every 4 hours (and on-demand) to scan all delivery lanes, detect unresolved blockers, classify failure type, and execute concrete recovery actions.

Trigger

• Cron: recovery-ticket-runner-4hourly
• Also called by: peter-deployment-recovery, social-post-failure-recovery-morning, social-post-failure-recovery-evening

Input

• Date (default: today Asia/Shanghai)
• v3-compiled-YYYY-MM-DD.json
• v3-closure-state-YYYY-MM-DD.json
• Recovery tickets in mission-control/data/recovery-tickets-v3/YYYY-MM-DD/
• Agent summaries

Layer Check Order (MUST follow in order)

1. Hunter raw — pain-map, selection-layer, intel-pack, delivery-receipt
2. JK processed — content writing package, processed receipt, source grounded
3. Elon X — social pack, live X URL, visibility proof, acceptance receipt
4. Elon LinkedIn — social pack, live LinkedIn URL, visibility proof
5. Mark Facebook — published post URL, engagement check receipt
6. Tony blog — drafts, artifact, ASSET_CHECK, source-publish receipt, blog QA receipt
7. Peter deploy — inserted-slug handoff, deploy receipt, live verification
8. Jenny activation — activation batch executed, receipt, ASSET_CHECK
9. Tully SEO — /skills/ pages written, skill-pages.ts updated, receipt

Failure Classification

Class	Meaning	Example
missing_proof	Work happened, proof missing	Post exists but no URL captured
execution_blocked	Script/tool failed	API timeout, auth error
missing_artifact	Upstream output missing	No Tony drafts for today
partial_success_with_debt	Some done, chain incomplete	X posted but acceptance missing
aggregate_coupling_failure	Child success lost in aggregate	X done but social lane blocked
human_required	Stop automation, wait for human	Account risk, policy issue

Recovery Actions by Lane

Tony Blog — GENERATED_NOT_PUBLISHED

• Check inputs: tony-content-artifact-YYYY-MM-DD.md, tony-asset-check-YYYY-MM-DD.json, tony-blog-preflight-YYYY-MM-DD.json
• If all inputs exist → RUN: node scripts/tony-blog-publish.mjs --date YYYY-MM-DD
• After publish → run blog QA → write blog-qa-receipt-YYYY-MM-DD.json
• Max attempts: 3 auto; escalate on attempt 4

Elon X / LinkedIn — GENERATED_NOT_PUBLISHED

• Check input: social-packs/elon-social-pack-YYYY-MM-DD-morning.json
• If input exists → construct Postiz payload → RUN: node scripts/postiz-publish.mjs --input /tmp/postiz-x.json --output /tmp/postiz-x-receipt.json
• Capture live URL + screenshot → write acceptance receipt
• Max attempts: 3 auto; escalate on attempt 4

Mark Facebook — TOOL_FAILURE

• Check auth: node scripts/facebook-verify-browser-use.mjs --check-auth
• If auth ok → retry publish with node scripts/facebook-poster.mjs --file /tmp/fb-post.txt
• If auth failed → classify human_required, write blocker receipt
• Max attempts: 2 auto

Jenny Activation — TOOL_FAILURE

• Check config: ~/.openclaw/workspace-jenny/.env must contain supabaseUrl
• If missing → classify human_required (Ray must fix config)
• If config ok → RUN: node workspace-jenny/scripts/jenny/send-activation-batch.mjs batch
• Max attempts: 2 auto

Peter Deploy — UPSTREAM_MISSING

• No action until Tony source-publish completes
• Auto-check every run: if tony-blog-source-publish-YYYY-MM-DD.json appears → RUN: node scripts/peter-blog-closeout-verify.mjs --date YYYY-MM-DD

Tully SEO

• If delivered but v3-compiled shows NOT_IN_SCOPE → file v3-compiled bug note, do not downgrade lane

Ticket Update Rules

For every run:

1. Read existing ticket from recovery-tickets-v3/YYYY-MM-DD/rt-YYYY-MM-DD-{lane}-NN.json
2. Append runner log entry with action: DIAGNOSIS or action: RECOVERY_ATTEMPT
3. If recovery script executed → add attempt_log entry with result
4. If state changed → update status, recoveryState, updated_at
5. If max_attempts reached → status: ESCALATED, notify

Output

• Write delivery-diagnosis-YYYY-MM-DD-HHMM.json to mission-control/data/
• Update recovery tickets
• Write runner log to recovery-runner-log/
• If escalation triggered → update Mission Control attention-required

Non-Goals

• Do not rewrite historical receipts into fake success
• Do not mask missing delivery with older historical wins
• Do not publish without brand gate pass
• Do not retry indefinitely; respect max_attempts

Safety

• Always prefer --dry-run first when testing a new publish path
• For external publish (X, LinkedIn, Facebook, blog), verify content with brand-positioning-tony.md before executing
• If auth/credential issue → human_required, do not brute-force