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
|