Remove every ward reference from sirens-echo: 54 references across 27 files, including the Go execution layer #946

New issue

Open

opened 2026-08-18 02:45:59 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-18 02:45:59 +00:00

Member

Filed by Olaf (ops seat) at Kai's direction, 2026-08-18.

I'm going to uninstall ward. literally uninstall. make a fj issue to delete every single reference to it in gaming/siren and bridge/deploy.

Ward was uninstalled from Kai's machine during this session. This issue covers coilyco-gaming/sirens-echo. Sibling: coilyco-bridge/deploy#656.

These two are not the same job. Deploy's is a config and docs sweep. This one is a refactor of running harness code, and it cannot be done by deletion.

Measured surface

At main as of filing:

54 word-boundary ward references across 27 files
69 further substring matches that are not ward (afterwards, toward, forward) and must survive

Categories:

bare ward - 26
ward-exec - 16
WardCommandRunner - 12, a Go type
WardJobExecutor - 9, a Go type
x-ward-role / x-ward-harness - 8, HTTP headers
.ward/ward.yaml - 6

Why this is a refactor, not a delete

Ward is not decoration here. It is the execution layer, live in:

internal/community/jobexec.go
internal/community/jobsubmit.go
internal/community/workspace.go
internal/community/executionguard.go
internal/community/proxy.go

plus their tests and docs/sirens-echo-execution.md, docs/sirens-echo-config.md.

WardJobExecutor and WardCommandRunner are the types that actually run jobs. Deleting them removes the capability, it does not rename it. So the first question is not "how do we remove ward", it is "what executes jobs afterwards". Options, none chosen here:

an in-process executor with no external binary
a different sandboxing layer
the capability goes away and the harness stops executing jobs at all, which is a product decision

Nothing should be deleted from internal/community/ until that is answered, or the lane loses job execution with no replacement.

The cross-repo header contract

x-ward-role and x-ward-harness are sent from here. On the other side, coilyco-bridge/deploy sends X-Ward-Run-ID in services/agent-proxy/scripts/verify-litellm-integration.sh and verify-trajectory.sh.

That namespace spans three places: this harness, agent-proxy, and deploy's verification scripts. Renaming or dropping it here alone breaks trajectory correlation in the ledger. It moves in lockstep across all three or not at all.

The substring trap

69 of the raw matches are afterwards, toward, forward. A case-insensitive substring sweep corrupts ordinary prose across the docs tree. Match on word boundaries and diff before landing - same hazard as forwardauth in deploy#656 and owl.glass in deploy#649.

Timing

Not before August 19. This is running code on the harness that serves both Sirens lanes, including the Dowel lane carrying the Temporal Vibe Check roughly 33 hours out. A refactor of the job execution path is not a pre-stream change.

Ward being uninstalled locally does not force this. It means Kai cannot invoke ward verbs by hand. The harness in the cluster runs whatever image was built, and that is unaffected until this lands.

Suggested order, once the executor question is answered

Docs and comments - free, no behaviour change, shrinks the surface for the real work.
.ward/ward.yaml - after checking what reads it. Per aos#778 it carries catalog metadata beyond workflow policy.
The X-Ward-* headers - coordinated across all three repos in one pass.
WardJobExecutor / WardCommandRunner - last, behind the replacement, with the existing tests in jobexec_test.go and grants_test.go kept green throughout as the safety net.

Done when

No word-boundary ward remains, .ward/ is gone, every afterwards and toward is untouched, job execution has a named and tested replacement, and the header change has landed in all three repos together.

coilyco-bridge/deploy#656 - sibling, the config half
coilyco-bridge/deploy#482 - the ward merge allowlist, moot once ward is gone

**Filed by Olaf (ops seat)** at Kai's direction, 2026-08-18. > I'm going to uninstall ward. literally uninstall. make a fj issue to delete every single reference to it in gaming/siren and bridge/deploy. Ward was uninstalled from Kai's machine during this session. This issue covers `coilyco-gaming/sirens-echo`. Sibling: coilyco-bridge/deploy#656. **These two are not the same job.** Deploy's is a config and docs sweep. **This one is a refactor of running harness code**, and it cannot be done by deletion. ## Measured surface At `main` as of filing: * **54 word-boundary `ward` references across 27 files** * 69 further substring matches that are **not** ward (`afterwards`, `toward`, `forward`) and must survive Categories: * bare `ward` - 26 * `ward-exec` - 16 * `WardCommandRunner` - 12, a Go type * `WardJobExecutor` - 9, a Go type * `x-ward-role` / `x-ward-harness` - 8, HTTP headers * `.ward/ward.yaml` - 6 ## Why this is a refactor, not a delete Ward is not decoration here. It is the **execution layer**, live in: ``` internal/community/jobexec.go internal/community/jobsubmit.go internal/community/workspace.go internal/community/executionguard.go internal/community/proxy.go ``` plus their tests and `docs/sirens-echo-execution.md`, `docs/sirens-echo-config.md`. `WardJobExecutor` and `WardCommandRunner` are the types that actually run jobs. Deleting them removes the capability, it does not rename it. **So the first question is not "how do we remove ward", it is "what executes jobs afterwards".** Options, none chosen here: * an in-process executor with no external binary * a different sandboxing layer * the capability goes away and the harness stops executing jobs at all, which is a product decision Nothing should be deleted from `internal/community/` until that is answered, or the lane loses job execution with no replacement. ## The cross-repo header contract `x-ward-role` and `x-ward-harness` are sent from here. On the other side, `coilyco-bridge/deploy` sends `X-Ward-Run-ID` in `services/agent-proxy/scripts/verify-litellm-integration.sh` and `verify-trajectory.sh`. That namespace spans **three** places: this harness, agent-proxy, and deploy's verification scripts. Renaming or dropping it here alone breaks trajectory correlation in the ledger. It moves in lockstep across all three or not at all. ## The substring trap 69 of the raw matches are `afterwards`, `toward`, `forward`. A case-insensitive substring sweep corrupts ordinary prose across the docs tree. Match on word boundaries and diff before landing - same hazard as `forwardauth` in deploy#656 and `owl.glass` in deploy#649. ## Timing **Not before August 19.** This is running code on the harness that serves both Sirens lanes, including the Dowel lane carrying the Temporal Vibe Check roughly 33 hours out. A refactor of the job execution path is not a pre-stream change. Ward being uninstalled locally does not force this. It means Kai cannot invoke `ward` verbs by hand. The harness in the cluster runs whatever image was built, and that is unaffected until this lands. ## Suggested order, once the executor question is answered 1. **Docs and comments** - free, no behaviour change, shrinks the surface for the real work. 2. **`.ward/ward.yaml`** - after checking what reads it. Per aos#778 it carries catalog metadata beyond workflow policy. 3. **The `X-Ward-*` headers** - coordinated across all three repos in one pass. 4. **`WardJobExecutor` / `WardCommandRunner`** - last, behind the replacement, with the existing tests in `jobexec_test.go` and `grants_test.go` kept green throughout as the safety net. ## Done when No word-boundary `ward` remains, `.ward/` is gone, every `afterwards` and `toward` is untouched, job execution has a named and tested replacement, and the header change has landed in all three repos together. ## Related * coilyco-bridge/deploy#656 - sibling, the config half * coilyco-bridge/deploy#482 - the ward merge allowlist, moot once ward is gone

coilyco-ops added the

labels

2026-08-18 02:45:59 +00:00

coilyco-ops referenced this issue

2026-08-18 20:39:11 +00:00

Epic: August 19 Temporal Vibe Check demo readiness, the work that is on camera #981

coilyco-ops added

priority