bug: trace actual loaded cortex plugin artifact and remove local-ahead deployment drift

[100yenadmin]

Problem

We have repeated live before_agent_start failures on the deployed Cortex plugin, but recent investigation quality has been poor because we keep mixing three different things:

1. source repo state (~/repos/evaos-cortex-plugin)
2. deployed local extension copy (~/.openclaw/extensions/cortex)
3. whatever artifact OpenClaw actually loaded into the running gateway process

Historically, we often edit locally first, leaving the local runtime ahead of GitHub. Later sync/download steps then overwrite or bypass those local patches. That means we can no longer trust repo inspection alone.

Goal

Trace the exact runtime path end-to-end:

• which plugin path is loaded by the running gateway
• which file (src, dist, or copied extension`) is actually executed
• which artifact contains the failing before_agent_start hook
• whether GitHub repo, local repo, deployed extension dir, and loaded runtime are in parity or drift

Deliverables

• exact path trace: GitHub ref -> local repo -> deployed extension dir -> loaded runtime artifact
• explanation of how the current live failure happened
• contingency actions for each drift mode
• durable fix so GitHub remains source of truth and local deploys cannot silently drift ahead

Acceptance criteria

• We can answer: "it fired from here, retrieved from here, and failed here" with exact file paths
• We can prove which copy the gateway is executing
• We have a GitHub-native workflow to prevent future local-ahead overwrite/loss cycles

Notes

This is trace-first, adversarial review required. Do not assume repo state equals runtime state.

[100yenadmin]

Deploy parity repair plan

Confirmed state:

• repo and deployed cortex plugin artifacts are not in parity
• deployed extension directory is acting like a mixed-state working copy, not a clean deploy target
• repo is also ahead/dirty locally, so tomorrow's deploy must be from a chosen committed GitHub ref, not from ambient local state

Recommended durable fix set:

1. add a real local deploy script, for example npm run deploy:local, that builds, syncs canonical payload into ~/.openclaw/extensions/cortex, prints pre/post hashes, and fails on mismatch
2. strengthen scripts/check-deploy-parity.sh to verify at minimum dist/index.js, dist/index.d.ts, openclaw.plugin.json, dist/openclaw.plugin.json, and optionally package.json
3. generate a deploy manifest with commit SHA plus artifact hashes and copy it into the deployed extension dir so "what is live" is answerable immediately
4. add a CI parity guard so committed dist/ cannot silently drift from source
5. document one blessed deploy path and explicitly ban hot-editing ~/.openclaw/extensions/cortex

Tomorrow operator runbook:

1. prove current drift with hashes/diffs
2. choose one canonical GitHub branch/SHA
3. build from that committed state
4. record source hashes
5. inspect and clean deploy-target contamination like root index.ts, root index.js, and stale .bak artifacts
6. sync canonical payload only: dist/, openclaw.plugin.json, and package.json if runtime expects it
7. verify exact parity before restart
8. restart gateway
9. validate plugin load plus a real before_agent_start memory-injection flow after restart

Operating rule going forward:

• GitHub repo is source of truth
• ~/.openclaw/extensions/cortex is deploy target only
• deploys come from committed refs
• parity check happens before every restart

This should be the umbrella issue for the deploy-drift repair lane.