139 lines
4.4 KiB
Markdown
139 lines
4.4 KiB
Markdown
---
|
||
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
|