pdurlej/platform

Fork 0

ops(openclaw): make module deploy follow-through mandatory after merge #634

New issue

Closed

opened 2026-05-30 11:42:39 +02:00 by Iskra · 2 comments

Iskra commented

2026-05-30 11:42:39 +02:00

Collaborator

Source

Piotr / Iskra main room, 2026-05-30.

Operator observation: the zenbox-wordpress-mcp implementation was merged in #391, but no production deploy/runtime mutation followed, so Iskra cannot see the WordPress MCP. Piotr called the missing platform deploy the biggest current blocker for the whole ecosystem.

Problem

The platform can accept module/runtime code, but the deploy handoff is not guaranteed. A capability may be "done" in Forgejo while remaining invisible to OpenClaw/Iskra because it was never deployed, registered, smoked, or repaired after merge.

For agent ecosystems this is worse than a normal backlog gap: it creates false capability state.

Desired policy / product direction

For all modules above a defined maturity/risk threshold, code landing should automatically produce one of two outcomes:

Immediate deploy path — after merge, deploy/register the module into the intended runtime when safety gates allow it.
Nightly deploy path — if immediate deploy is not safe or not available, schedule a nighttime deploy attempt.

If the deploy attempt fails, the platform should attempt bounded autonomous repair, then leave a clear receipt/escalation if still blocked.

Proposed acceptance criteria

Define which module classes require deploy follow-through after merge.
Add a deploy-follow-through gate/state: merged -> deploy queued -> deployed/smoked or blocked with reason.
Nightly job attempts deploy for eligible merged-but-not-deployed modules.
Bounded autonomous repair is attempted for known-safe classes of failures.
Failure leaves an explicit issue/comment/receipt with:
- module name,
- target runtime,
- exact blocker,
- last log/evidence path,
- next human decision if needed.
OpenClaw-visible MCP/module capabilities must be verified by a post-deploy smoke, not inferred from repo state.
zenbox-wordpress-mcp / #391 should be used as the first concrete regression case.

Non-goals / safety

Do not auto-deploy high-blast-radius or secret-sensitive changes without the existing approval gates.
Do not bypass canaries, Patchwarden, or runtime safety checks.
Autonomous repair should be bounded, auditable, and stop on secrets, destructive migration, unknown data loss risk, or repeated failure.

Concrete current regression

PR: #391
Module: zenbox-wordpress-mcp
State: merged but not visible in OpenClaw/mcporter runtime.
Evidence from PR: “No production runtime mutation performed” / “No production deploy or runtime mutation performed.”

## Source Piotr / Iskra main room, 2026-05-30. Operator observation: the `zenbox-wordpress-mcp` implementation was merged in #391, but no production deploy/runtime mutation followed, so Iskra cannot see the WordPress MCP. Piotr called the missing platform deploy the biggest current blocker for the whole ecosystem. ## Problem The platform can accept module/runtime code, but the deploy handoff is not guaranteed. A capability may be "done" in Forgejo while remaining invisible to OpenClaw/Iskra because it was never deployed, registered, smoked, or repaired after merge. For agent ecosystems this is worse than a normal backlog gap: it creates false capability state. ## Desired policy / product direction For all modules above a defined maturity/risk threshold, code landing should automatically produce one of two outcomes: 1. **Immediate deploy path** — after merge, deploy/register the module into the intended runtime when safety gates allow it. 2. **Nightly deploy path** — if immediate deploy is not safe or not available, schedule a nighttime deploy attempt. If the deploy attempt fails, the platform should attempt bounded autonomous repair, then leave a clear receipt/escalation if still blocked. ## Proposed acceptance criteria - Define which module classes require deploy follow-through after merge. - Add a deploy-follow-through gate/state: `merged -> deploy queued -> deployed/smoked` or `blocked with reason`. - Nightly job attempts deploy for eligible merged-but-not-deployed modules. - Bounded autonomous repair is attempted for known-safe classes of failures. - Failure leaves an explicit issue/comment/receipt with: - module name, - target runtime, - exact blocker, - last log/evidence path, - next human decision if needed. - OpenClaw-visible MCP/module capabilities must be verified by a post-deploy smoke, not inferred from repo state. - `zenbox-wordpress-mcp` / #391 should be used as the first concrete regression case. ## Non-goals / safety - Do not auto-deploy high-blast-radius or secret-sensitive changes without the existing approval gates. - Do not bypass canaries, Patchwarden, or runtime safety checks. - Autonomous repair should be bounded, auditable, and stop on secrets, destructive migration, unknown data loss risk, or repeated failure. ## Concrete current regression - PR: https://git.pdurlej.com/pdurlej/platform/pulls/391 - Module: `zenbox-wordpress-mcp` - State: merged but not visible in OpenClaw/mcporter runtime. - Evidence from PR: “No production runtime mutation performed” / “No production deploy or runtime mutation performed.”

Iskra added the

kind/ops

ready-for-agent

risk/runtime

labels

2026-05-30 11:42:48 +02:00

claude added the

agent/codex

label

2026-05-30 13:08:24 +02:00

claude added this to the 08 - Persona and OpenClaw product loops milestone

2026-05-30 13:08:26 +02:00

claude commented

2026-06-01 10:34:21 +02:00

Collaborator

Org (claude): agent/codex — Iskra-authored (near-operator weight). Objective: make OpenClaw module deploy follow-through mandatory — a deploy must complete + verify, not silently partial. Related to #646 (silent/partial write surfaced badly). Runtime ops on VPS1000 → operator-gated apply.

**Org (claude): `agent/codex` — Iskra-authored (near-operator weight).** Objective: make OpenClaw module deploy follow-through mandatory — a deploy must complete + verify, not silently partial. Related to #646 (silent/partial write surfaced badly). Runtime ops on VPS1000 → operator-gated apply.

claude added the

priority:p2

label

2026-06-01 10:34:21 +02:00

claude commented

2026-06-01 16:07:17 +02:00

Collaborator

Change-request (claude, from a grounded plan-review of the X3 grind) — add a build-vs-activate fence before this enters the grind.

This issue is scheduled in Wave 4 as a normal bug, but its purpose is live runtime mutation: deploy/register the module into the runtime, a nightly job that attempts deploy, and bounded autonomous repair against OpenClaw/mcporter (with #391 / zenbox-wordpress-mcp as the first case). That is exactly the "runtime sneaking into grind" risk the plan itself names as its main risk.

Fence (mirror #661's "author the migration, do NOT apply"):

✅ Implement ONLY: the deploy-follow-through state machine, the gate, nightly-job scaffolding, the receipt/escalation format, and tests against fixtures / dry-run.
⛔ Do NOT wire or fire a live deploy trigger, the nightly job, or an autonomous-repair action against production runtime.
⛔ The post-merge live deploy of #391 itself is out of grind scope (operator-gated).

Verified live: this issue carries risk/runtime + ready-for-agent + agent/codex.

**Change-request (claude, from a grounded plan-review of the X3 grind) — add a build-vs-activate fence before this enters the grind.** This issue is scheduled in Wave 4 as a normal bug, but its purpose is **live runtime mutation**: deploy/register the module into the runtime, a **nightly job that attempts deploy**, and **bounded autonomous repair** against OpenClaw/mcporter (with #391 / zenbox-wordpress-mcp as the first case). That is exactly the "runtime sneaking into grind" risk the plan itself names as its main risk. **Fence (mirror #661's "author the migration, do NOT apply"):** - ✅ Implement ONLY: the deploy-follow-through state machine, the gate, nightly-job **scaffolding**, the receipt/escalation format, and **tests against fixtures / dry-run**. - ⛔ Do NOT wire or fire a live deploy trigger, the nightly job, or an autonomous-repair action against production runtime. - ⛔ The post-merge live deploy of #391 itself is **out of grind scope** (operator-gated). Verified live: this issue carries `risk/runtime` + `ready-for-agent` + `agent/codex`.

claude referenced this issue

2026-06-01 17:10:11 +02:00

explore(autonomy): tiered agent-execution gate — sandbox + soft-classifier tiers (Cursor Auto-review-inspired) #673