feat(autoheal): deploy drift probe from Iskra #142 #65

New issue

Closed

opened 2026-05-28 21:44:06 +02:00 by codex · 1 comment

codex commented

2026-05-28 21:44:06 +02:00

Collaborator

Purpose

Extract the useful product/design value from pdurlej/iskra-openclaw#142 without turning Iskra into two competing deploy systems.

Source context: pdurlej/iskra-openclaw#142 proposed a fast incremental iskra-deploy wrapper with plan/sync/smoke, sidecar manifest, remote lock, backup, and post-deploy evidence. The operator decision on 2026-05-28: do not merge it as a second deployer; move the reusable knowledge into Patchwarden / supervised auto-heal.

Product value to keep

Patchwarden should be able to support this lane:

incident/probe -> remediation proposal -> deploy drift plan -> explicit operator acceptance -> allowlisted apply -> postcheck -> dashboard

The useful #142 concepts are:

local/remote deploy drift detection,
manifest-based changed-file summary,
operator-readable deploy plan before touching production,
lock semantics to avoid concurrent repair/deploy actions,
backup/rollback metadata before allowed mutation,
smoke/postcheck evidence after mutation,
append-only receipt fields for later agent/operator audit.

Do not copy from #142 as-is

Do not make Patchwarden a second production deployer.

Out of scope for the first slice:

full sync/apply,
direct root SCP deployment path,
replacing scripts/iskra-openclaw-deploy.sh,
automatic production mutation,
hidden gateway/systemd restart,
auto-heal without explicit operator acceptance.

Proposed first slice

Add a Patchwarden/auto-heal design and read-only probe shape for deploy drift:

Define a deploy_drift_probe or equivalent finding type.
Produce a plan object that can say: changed files, expected target paths, risk class, recommended executor, required postchecks.
Keep default mode read-only/proposal-only.
Make it compatible with Iskra's existing supervised auto-heal contracts rather than creating a new deploy authority.

Acceptance

#142 is explicitly referenced as superseded source material, not merged implementation.
Patchwarden has a documented deploy-drift/repair planning lane.
The first implementation, if any, is read-only/proposal-only.
Any future apply path is allowlisted, receipt-backed, and requires explicit operator acceptance.
Existing canonical deploy runbook remains canonical until separately changed.

Non-goals

Building a general CI/CD deployer.
Making Patchwarden mutate production by default.
Reintroducing root-SCP fast deploy as an implicit shortcut.
Replacing Iskra's current deploy runbook in this issue.

Refs: pdurlej/iskra-openclaw#142

## Purpose Extract the useful product/design value from `pdurlej/iskra-openclaw#142` without turning Iskra into two competing deploy systems. Source context: `pdurlej/iskra-openclaw#142` proposed a fast incremental `iskra-deploy` wrapper with plan/sync/smoke, sidecar manifest, remote lock, backup, and post-deploy evidence. The operator decision on 2026-05-28: do not merge it as a second deployer; move the reusable knowledge into Patchwarden / supervised auto-heal. ## Product value to keep Patchwarden should be able to support this lane: `incident/probe -> remediation proposal -> deploy drift plan -> explicit operator acceptance -> allowlisted apply -> postcheck -> dashboard` The useful #142 concepts are: - local/remote deploy drift detection, - manifest-based changed-file summary, - operator-readable deploy plan before touching production, - lock semantics to avoid concurrent repair/deploy actions, - backup/rollback metadata before allowed mutation, - smoke/postcheck evidence after mutation, - append-only receipt fields for later agent/operator audit. ## Do not copy from #142 as-is Do not make Patchwarden a second production deployer. Out of scope for the first slice: - full `sync/apply`, - direct root SCP deployment path, - replacing `scripts/iskra-openclaw-deploy.sh`, - automatic production mutation, - hidden gateway/systemd restart, - auto-heal without explicit operator acceptance. ## Proposed first slice Add a Patchwarden/auto-heal design and read-only probe shape for deploy drift: 1. Define a `deploy_drift_probe` or equivalent finding type. 2. Produce a plan object that can say: changed files, expected target paths, risk class, recommended executor, required postchecks. 3. Keep default mode read-only/proposal-only. 4. Make it compatible with Iskra's existing supervised auto-heal contracts rather than creating a new deploy authority. ## Acceptance - #142 is explicitly referenced as superseded source material, not merged implementation. - Patchwarden has a documented deploy-drift/repair planning lane. - The first implementation, if any, is read-only/proposal-only. - Any future apply path is allowlisted, receipt-backed, and requires explicit operator acceptance. - Existing canonical deploy runbook remains canonical until separately changed. ## Non-goals - Building a general CI/CD deployer. - Making Patchwarden mutate production by default. - Reintroducing root-SCP fast deploy as an implicit shortcut. - Replacing Iskra's current deploy runbook in this issue. Refs: pdurlej/iskra-openclaw#142

codex referenced this issue

2026-06-07 17:33:11 +02:00

feat(openclaw): supervised runtime repair gate for Iskra auto-heal #68

codex commented

2026-06-07 17:33:12 +02:00

Author

Collaborator

Context from pdurlej/iskra-openclaw#27 migration:

This issue remains useful as the deploy drift probe slice. The broader supervised OpenClaw runtime repair gate now lives in Patchwarden issue #68:

#68

Boundary: #65 should stay focused on deploy drift evidence/plan shape. It should not become a second deployer and should not perform production mutation.

Context from `pdurlej/iskra-openclaw#27` migration: This issue remains useful as the **deploy drift probe slice**. The broader supervised OpenClaw runtime repair gate now lives in Patchwarden issue #68: https://git.pdurlej.com/pdurlej/patchwarden/issues/68 Boundary: #65 should stay focused on deploy drift evidence/plan shape. It should not become a second deployer and should not perform production mutation.