Skip to content

Harness updates phase 1: update action, version stamping, stale flag (issue #250) - #272

Closed
theogravity wants to merge 29 commits into
mainfrom
docs/harness-updates-spec
Closed

theogravity wants to merge 29 commits into
mainfrom
docs/harness-updates-spec

Conversation

@theogravity

Copy link
Copy Markdown
Contributor

Implements Phase 1 of the harness-updates spec (docs/superpowers/specs/2026-09-28-harness-updates-design.md, issue #250): an Update action for harness CLIs on the control-plane host (vendor command where the manifest declares one, re-run installer otherwise), the harness version each pane launched on stamped per subshell (compare-and-set, restamped after a remote detect), and a server-derived stale flag the card renders as a detail line. Adds the agent.update audit event.

Phase 2 is reserved in the spec, not built here: the remote-node signed update command, exact at-spawn versions, and turn-end auto-restart.

The PR carries spec, plan, and implementation (16 commits).

… version stamping, server-derived staleness
…ask 6 fallout)

Route-level sims never saw the version-refresh detect kick: filter the
unawaited detect frames out of exact-wire-order assertions with the new
scripted-node foregroundTypes(), the ws suite's viewers-frame pattern.
The local 200-path stubs answer --version like the manager suites' stubs
already do; the bare sleep stub made every awaited create pay the probe's
4 s deadline, timing out the label-rule test.
@theogravity
theogravity deleted the docs/harness-updates-spec branch October 12, 2026 05:17
@github-actions github-actions Bot locked and limited conversation to collaborators Oct 12, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant