Graph task: sdn-lifecycle-owner-approval-stale-authority · state: open · priority: 1 · components: [sdn, stack]
Agent: Hermes
BLOCKED on sdn-dashboard-wave3-service-lifecycle (2026-07-30): Cannot land 28 deployed commits on main while one of them (a8a03e5, RESTART/STOP host half) is gated by a task whose body still reads 'OWNER-STOPPED - do not design, do not build'. An agent's commit message asserting 'the owner approved' is not owner consent and ATHENA will not clear a host-capability STOP on it. Needs the owner's word, then the stale marker corrected per VERIFY THE PREMISE.
Filed by ATHENA 2026-07-30 while trying to satisfy the owner's brand-new LAND ON MAIN + TAG law
on the node dashboard. This one stale marker is the reason the owner had to report the same
defect three times, and the reason 28 deployed commits are still off main. It is a
five-minute fix by whoever holds the answer, and I am explicitly NOT deciding it.
The contradiction, both sides quoted
graph/tasks/sdn-dashboard-wave3-service-lifecycle.md — state claimed, and its body still says:
WAITING: OWNER-STOPPED per Hermes charter: no daemon-lifecycle endpoint exists anywhere in the
node; creating one is remote process control over HTTP = new host capability + trust-model
expansion (auth half is Seal Council). Needs owner authorization before any design.
STATUS: OWNER-STOPPED — do not design, do not build, until the owner authorizes
space-data-network commit a8a03e5b (2026-07-30 07:49:05 -0400) — "node: the lifecycle verbs
the owner authorized, under the conditions the Council set":
RESTART and STOP, host half. The owner approved the capability on 2026-07-30 ("approved"); the
Seal Council (Hermes + Hephaestus, same day) set the conditions and DISSENTED from my first auth
proposal. This is the design that came out of that, not the one that went in.
So the task says do not build and a commit says the owner approved it and here is the build.
One of those is stale. Almost certainly the task body — nobody went back and lifted the STOP after
the owner said "approved" — but a commit message written by an agent is not owner consent, and
I will not treat it as such, so I am not clearing the STOP on its authority.
⛔ Why ATHENA did not merge, and will not until this is settled
The deployed lineage is origin/iris-menu-label-purge@077e96d4, 28 commits ahead of
origin/main, and a8a03e5b is one of them. Merging the deployed tip to main — which the new law
otherwise requires — would land remote process control over HTTP (RESTART/STOP on a live
host) onto main on the strength of a marker that currently reads do not build. That is the one
class of change that must never arrive by side effect. Iris hit the same wall and correctly recorded
the blocker instead of forcing it; this task is that blocker, named.
For the record, the design in a8a03e5b is not careless — it costs a FRESH WALLET SIGNATURE over a
single-use server nonce binding verb + resolved unit + session identity, 120 s TTL, nonce consumed
BEFORE verification so a failed attempt burns it, after Hephaestus DISSENTED from a
cookie+CSRF+confirm-token proposal as "a bearer credential darkening a live host". The concern is
provenance of the authorization, not the engineering.
Measured, so nobody re-litigates it from memory
- The live anonymous render carries no
RESTART and no STOP SERVICE (both grep -c = 0),
consistent with the task's own note. So the UI half is not exposed to anonymous visitors.
- HTTP status is useless as evidence here and must not be cited:
/api/node/service,
/api/service and /api/node/restart all return 401 — but so do
/api/definitely-not-a-real-route-xyz and /api/node/zzzz. Auth middleware runs before routing,
so 401 says nothing about whether a route exists. Any future claim that "the endpoint is/isn't
deployed" based on a 401 is inadmissible.
⚠ The revert hazard this is holding open — the actual root cause of three owner reports
hermes-dash5-wave23 is a stale branch that does NOT contain
Mirrored from the dev graph (graph/tasks/sdn-lifecycle-owner-approval-stale-authority.md in DigitalArsenal/spacedatanetwork-stack); closes automatically when the graph task completes.
Graph task:
sdn-lifecycle-owner-approval-stale-authority· state: open · priority: 1 · components: [sdn, stack]Agent: Hermes
Filed by ATHENA 2026-07-30 while trying to satisfy the owner's brand-new LAND ON MAIN + TAG law
on the node dashboard. This one stale marker is the reason the owner had to report the same
defect three times, and the reason 28 deployed commits are still off
main. It is afive-minute fix by whoever holds the answer, and I am explicitly NOT deciding it.
The contradiction, both sides quoted
graph/tasks/sdn-dashboard-wave3-service-lifecycle.md— stateclaimed, and its body still says:space-data-networkcommita8a03e5b(2026-07-30 07:49:05 -0400) — "node: the lifecycle verbsthe owner authorized, under the conditions the Council set":
So the task says do not build and a commit says the owner approved it and here is the build.
One of those is stale. Almost certainly the task body — nobody went back and lifted the STOP after
the owner said "approved" — but a commit message written by an agent is not owner consent, and
I will not treat it as such, so I am not clearing the STOP on its authority.
⛔ Why ATHENA did not merge, and will not until this is settled
The deployed lineage is
origin/iris-menu-label-purge@077e96d4, 28 commits ahead oforigin/main, anda8a03e5bis one of them. Merging the deployed tip tomain— which the new lawotherwise requires — would land remote process control over HTTP (
RESTART/STOPon a livehost) onto
mainon the strength of a marker that currently reads do not build. That is the oneclass of change that must never arrive by side effect. Iris hit the same wall and correctly recorded
the blocker instead of forcing it; this task is that blocker, named.
For the record, the design in
a8a03e5bis not careless — it costs a FRESH WALLET SIGNATURE over asingle-use server nonce binding verb + resolved unit + session identity, 120 s TTL, nonce consumed
BEFORE verification so a failed attempt burns it, after Hephaestus DISSENTED from a
cookie+CSRF+confirm-token proposal as "a bearer credential darkening a live host". The concern is
provenance of the authorization, not the engineering.
Measured, so nobody re-litigates it from memory
RESTARTand noSTOP SERVICE(bothgrep -c= 0),consistent with the task's own note. So the UI half is not exposed to anonymous visitors.
/api/node/service,/api/serviceand/api/node/restartall return401— but so do/api/definitely-not-a-real-route-xyzand/api/node/zzzz. Auth middleware runs before routing,so
401says nothing about whether a route exists. Any future claim that "the endpoint is/isn'tdeployed" based on a 401 is inadmissible.
⚠ The revert hazard this is holding open — the actual root cause of three owner reports
hermes-dash5-wave23is a stale branch that does NOT containMirrored from the dev graph (
graph/tasks/sdn-lifecycle-owner-approval-stale-authority.mdin DigitalArsenal/spacedatanetwork-stack); closes automatically when the graph task completes.