sub2api-cn-relay-manager/.agent/skills/remote-truth-closure/SKILL.md

name, description

name

description

remote-truth-closure

Drive long-running implementation tasks all the way through local gates, commit and push, remote deployment, real verification, and truthful status reporting. Use this whenever the user asks to continue a multi-step task, deploy to a real server, verify whether something is truly complete, push to multiple remotes, clean a noisy remote environment, or recover a task that may have drifted from reality. Also use it for Chinese requests such as “继续推进”, “部署到 remote43”, “是否真实验证”, “任务是否完成”, or “推到三个仓库”.

Remote Truth Closure

This skill exists to prevent false completion.

Core idea:

local green != task complete

A task is only complete when the truth chain is closed:

1. local code and tests
2. commit and push
3. real deployment target updated
4. real endpoint or real user path verified
5. status board updated truthfully

When to use

Use this skill when any of the following are true:

• The user asks to continue a long-running implementation
• The task includes deploy, push, restart, remote verification, or cleanup
• The user asks whether something is really done
• You need to compare local state vs remote truth
• You are updating EXECUTION_BOARD.md or an equivalent source of truth

Principles

• Prefer evidence over assumptions
• Keep code changes and verification records separate
• Treat remote cleanup as part of verification quality
• Never let docs claim more than the evidence supports

Workflow

1. Reconstruct current truth

• Check tracked vs untracked changes
• Confirm repo, branch, target server, and active instance directory
• Read the latest execution board or runbook before changing it
• Identify whether previous progress was local-only or remotely verified

2. Close the local gate

• Add or update regression tests first
• Run the repo’s required quality gates
• Confirm the exact bug or missing behavior before implementing the fix

3. Commit in two layers

Prefer two commits when appropriate:

• feature or fix commit
• verification or documentation commit

This keeps behavior changes separate from proof recording.

4. Deploy carefully

When deploying to a fixed checkout:

• update the checkout to the exact target commit
• fetch to a temporary ref if the checked-out branch refuses direct fetch
• replace the real app binary, not just a build artifact
• stop the active listener PID explicitly
• restart from the real app directory with the real env file loaded

5. Verify remotely

Always verify:

• /healthz
• the actual API or page you changed
• the exact request path the user cares about

If possible, verify the running commit or binary hash.

Verification hierarchy

Trust signals in this order:

1. real user data plane result
2. host usage_logs or equivalent request evidence
3. route decision or sticky or failover logs
4. provider or inventory projections
5. probe-only diagnostics

If a lower-level status disagrees with a higher-level proof, treat it as a false-negative candidate.

Remote cleanup

Use cleanup to reduce noise, not to hide evidence.

• Keep one active app directory and one latest fixed checkout when possible
• Remove stale bundles, duplicate stacks, and dead helper processes only after confirming they are inactive
• Clean temporary test entities after verification if they would pollute future checks

Status board rules

Only update the execution board after you have evidence.

Each verification entry should capture:

• exact commit IDs
• local gates run
• remote target updated
• concrete endpoint or request used
• key returned values
• what remains noisy or incomplete

Never write “completed” if deployment or remote verification is still blocked.

Final answer checklist

Before claiming completion, confirm all of these:

• local tests passed
• intended files were committed
• push to all required remotes succeeded
• target remote is running the intended commit
• the changed endpoint or user path was verified on the real target
• docs were updated truthfully
• unrelated artifacts were not accidentally committed

Anti-patterns

Avoid these:

• claiming done after local tests only
• using doc text as proof of behavior
• restarting by process name when multiple binaries may exist
• trusting stale probe noise over real successful requests
• committing scratch artifacts or research notes by accident