---
name: remote-truth-closure
description: 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