deploy: a change to agent/instructions.md never reaches the live agent

[EthanThatOneKid]

Expected. agent/instructions.md is the canonical prompt, and system/persona.md in the agent's memory is seeded from it. A merge that edits the prompt should leave the live agent answering from the edited text.

Actual. Two independent gaps, so a prompt change reaches the live agent only if a person remembers to run sync-persona by hand:

1. .github/workflows/deploy.yml filters on channels/http/**, channels/discord/**, lib/**, scripts/**, package.json, package-lock.json, and the workflow itself. agent/** is absent, so a prompt-only change triggers no deploy at all.
2. scripts/zo-deploy.ts fast-forwards the live checkout and restarts each service, but never runs sync-persona. Even a deploy that does run leaves system/persona.md on the previous text.

Cost. After #7 merged on 2026-09-26 the live persona was still the pre-cutover text. npm run sync-persona -- --dry-run reported system/persona.md differs from agent/instructions.md (5174 bytes rendered), and the agent only caught up when npm run sync-persona was run by hand (memory checkout commit 0a2928a). Nothing in CI or the deploy surfaces the drift.

Recommended fix. Add agent/instructions.md to the deploy path filter and run npm run sync-persona on the host in the same job, before the services restart. The deploy client already runs host commands (zo.callTool("bash", { cmd }), scripts/zo-deploy.ts:188), so this needs no new capability. A host-side automation that runs sync-persona when it drifts would close the same gap without touching CI.

[EthanThatOneKid]

Consolidating #17 into this issue — it is a duplicate of this one, filed ~20 min later by the same account while working the same gap.

#17's unique evidence, folded in here:

• The run-level proof: eb59a21 (the docs: give Data a memory it lands itself, in its own checkout #7 merge) produced verify completed/success and no deploy run, while 39cc623 (the fix: recover from a Letta conversation the backend no longer has #14 merge, which touched channels/http/**) produced both deploy and verify. So the path filter, not a failure, is what skipped the sync.
• grep -rn "sync-persona|agent/" .github/ returns nothing — no workflow references either the script or the prompt path.
• The reusable hook for the fix: runCommand at scripts/zo-deploy.ts:187 already drives Zo's bash MCP tool (zo.callTool("bash", { cmd })), so running the sync from the deploy job needs no new plumbing.
• The drift is currently closed by hand: npm run sync-persona -- --dry-run now reports system/persona.md already matches agent/instructions.md (checked 2026-09-26), after the memory checkout picked up commit 0a2928a.

[EthanThatOneKid]

Consolidating the extra evidence from #17 (filed minutes after this one by mistake; closed as a duplicate of this issue).

The gap is visible in the run history. The merge of #7 (eb59a21, 2026-09-26) touched agent/instructions.md (41 lines), README.md, and AGENTS.md, and ran exactly one workflow:

$ gh run list --repo wazootech/data --limit 20 --json name,status,conclusion,headSha
# filtered to eb59a21
verify completed/success

No deploy run exists for that commit. Compare #14 (39cc623), which touched channels/http/** and did produce one:

deploy completed/success
verify completed/success

Nothing in CI invokes the sync. Both workflows are deploy.yml and verify.yml, and:

$ grep -rn "sync-persona\|agent/" .github/
(none)

The fix needs no new plumbing. scripts/zo-deploy.ts already drives host commands:

• runCommand(zo, cmd) at scripts/zo-deploy.ts:187 calls zo.callTool("bash", { cmd }) and throws on a non-zero result via assertOk.
• It is what the fast-forward and the restart-wait already use.

So the change is: add "agent/**" to on.push.paths in .github/workflows/deploy.yml, then run the sync on the host in the same job, before the services restart — either a new flag on scripts/zo-deploy.ts (e.g. --run "npm run sync-persona") or its own step using the same credential. Sequencing matters: the sync must run after the fast-forward that brings the new agent/instructions.md onto the host.

[EthanThatOneKid]

Moot as of #22. The drift this tracked was between agent/instructions.md and the copy seeded into a self-hosted Letta agent's memory; that runtime is retired, so there is no second copy left to drift. Reopen if the Letta path comes back.