agent-pages

Phase 5 handoff: Zulip control-plane parity

Download

Phase 5 handoff: Zulip control-plane parity

Instruction to the next agent

Implement Phase 5 of the OpenClaw–Zulip integration: control-plane parity. Work from the existing repositories and live working tree; do not assume a clean checkout. Begin with a read-only recovery assessment in both repositories, then report the recovered state and a bounded implementation plan before making changes.

The owner has established a mandatory delegation workflow for large, divisible implementation work: use focused, non-overlapping gpt-5.6-luna sub-agents at xhigh reasoning, with strict file ownership and acceptance criteria. Keep cross-cutting decisions, shared integration surfaces, live operations, and final verification with the main agent. The main agent must inspect every actual diff and test result rather than accepting sub-agent summaries as proof.

Preserve every existing staged, unstaged, and untracked change. Never use git reset, git clean, destructive checkout/restore operations, broad overwrites, or deletion of runtime state. Do not commit, push, deploy, restart services, edit live jobs, or mutate production until the owner explicitly authorizes that exact operation.

Authoritative scope

The durable phase plan is:

/root/zulip/docs/openclaw-zulip-integration-plan.md

Its Phase 5 contract is:

Phase 5 exit criteria:

Do not expand Phase 5 into RSS migration, semantic video support, a Zulip Server upgrade, an OpenClaw core fork, or Discord retirement. RSS is still deferred pending a MonitorRSS OPML export. Phase 6 owns the longer dual-channel canary and any optional Discord cutover.

Repository and production context

At handoff creation, /root/openclaw HEAD and origin/master are both commit 3f91b11 (docs: close phase 4 acceptance). The Phase 4 series has been committed and pushed. The working tree is still intentionally dirty with runtime-generated curator/config files and unrelated untracked artifacts. Treat the live tree as authoritative and preserve all of it.

The /root/zulip plan repository was clean at commit 3e2dfb0, but its top-level status prose still describes Phase 3-era runtime state. Use its Phase 5 definition as authoritative scope while using /root/openclaw/AGENTS.md, /root/openclaw/openclaw-data/workspace/MEMORY.md, and actual runtime inspection for current Phase 4 facts.

Phase 4 baseline that must remain intact

Phase 4 is complete and accepted:

The current control plane is still Discord-centric in important places. At handoff creation, read-only inspection showed:

These observations are starting points, not permission to copy Discord configuration keys blindly into Zulip. Verify the deployed OpenClaw schema and plugin SDK behavior first.

Required first pass: read-only recovery

Run bounded inspection first:

cd /root/openclaw
git status --short --branch
git diff --stat
git diff --cached --stat
git log --oneline --decorate -n 20

git -C /root/zulip status --short --branch
git -C /root/zulip log --oneline --decorate -n 10

Read completely before changing anything:

Then locate, with bounded rg searches:

Report exact relevant dirty files, staged state, current control-plane behavior, what is reusable, what is missing, and whether any required feature genuinely needs an OpenClaw core change. Core changes are out of scope unless the owner explicitly approves an architecture review.

Recommended non-overlapping delegation

Use Luna/xHigh agents only for bounded workstreams. A safe initial split is:

  1. Authorization audit — read-only mapping of owner commands, elevated authorization, sender normalization, and tests. No edits.
  2. Approval/private-routing audit — read-only mapping of approval adapters, /approve, expiry/duplicate semantics, diagnostics privacy, and failure notices. No edits.
  3. Status-probe audit — read-only mapping of external channel status lifecycle and the current not-running quirk. No edits.

After the main agent chooses an architecture, delegate implementation by disjoint file ownership. Do not let multiple agents edit openclaw.json, the same plugin source file, or shared docs concurrently. The main agent owns configuration integration, live operations, and final acceptance.

Implementation requirements

Numeric-owner authorization

Private approvals and /approve

Private diagnostics and failure notices

Channel status probe

Compatibility and fallback

Test strategy

Add focused mocked tests before any live work. Cover at minimum:

Run targeted tests and static checks first. Bound all output. Before presenting a candidate for promotion, require at least:

cd /root/openclaw/plugins/openclaw-zulip
npm run check
npm audit --omit=dev

Also use a clean disposable OpenClaw state to validate package installation, config schema, plugin inspection, doctor, and status behavior. Do not treat a source-tree build alone as deployable proof. Build an immutable artifact, record its version, SHA-256, npm integrity/shasum, file inventory, and compatibility result.

Controlled live acceptance plan

Do not execute this section without explicit owner authorization for the exact candidate and operations.

Use a dedicated private canary context and verify one case at a time:

  1. Owner DM command succeeds; same text from an unauthorized numeric user is rejected without privileged execution.
  2. A harmless elevated action produces one approval request only in owner DM.
  3. Valid owner /approve executes exactly once and returns a bounded private result.
  4. Repeating the same approval does not execute again.
  5. An intentionally expired approval fails safely and remains private.
  6. /diagnostics invoked in DM remains private; invocation from channel 4 does not leak output there.
  7. A controlled approval/failure notice reaches owner DM and exercises the expected iOS notification/badge path.
  8. Restart the gateway around a pending or resolved canary and verify no duplicate prompt, decision, or execution.
  9. Verify the Zulip status probe against logs and durable ingress state.
  10. Re-run Discord owner command, approval DM, and private diagnostics regression checks.

Record exact Zulip message IDs, sender IDs, destinations, approval IDs in safely redacted form, journal/session evidence, execution count, and gateway health. Screenshots are useful for physical privacy/UI acceptance, but API and durable-state evidence are also required.

Acceptance checklist

Known operational cautions

Expected handoff from Phase 5

Before requesting promotion approval, provide the owner with: