Ward-backed execution and per-job workspace

coilyco-ops commented

2026-08-12 11:11:24 +00:00

Member

Outcome

A job can run commands against a real repository checkout, inside a governed execution boundary, in a workspace scoped to that job.

Why

This is the unit that makes the harness a dev platform rather than an agent that talks about dev work. It is also the one with the largest blast radius, so it is deliberately last in dependency order behind the job record.

Scope

Item 9 - sandboxed execution.

Execution goes through coilyco-flight-deck/ward, the existing governed execution layer for unattended agents in isolated repository workflows. This unit integrates it; it should not grow a second execution path.
The current pod posture is readOnlyRootFilesystem: true with all capabilities dropped and no exec surface whatsoever. That posture is the correct default and this unit must state precisely what it relaxes, where, and why.
Execution is bounded: wall-clock, output size, and what the job may reach on the network.

Item 10 - workspace.

A per-job working directory, created on start and removed on terminal state.
Repository checkout into that workspace.
Workspace is not shared between jobs. Two concurrent jobs cannot see each other's files.

A boundary this unit inherits, stated plainly

Items 5 through 8 - per-requester authority, attribution, authorization beyond admission, and approval gates - were not approved in this batch. That is a legitimate scoping choice, and it has a consequence this unit should carry openly rather than discover later:

Execution will run under pod-level authority with no per-requester attribution. Every job, whoever asked for it, acts as the same identity with the same grants. Nothing in the audit trail distinguishes them.

That is acceptable while the admission policy is a direct-message allowlist of one account, because the requester set and the trusted principal are the same person. It stops being acceptable the moment the surface widens - see the guild decision in coilyco-bridge/deploy#365.

Recommendation: do not land this unit and a widened admission surface in the same window. If the guild opens first, items 5 and 6 should come before this unit rather than after it. Sequencing, not a veto.

Acceptance

A job checks out a repository and runs a bounded command in an isolated workspace.
Two concurrent jobs cannot observe each other's files.
Workspaces are removed when the job reaches a terminal state, including on cancellation and crash.
The relaxation of the pod security posture is documented against what it was.

Depends on

#143 - jobs must exist before they can own a workspace.
Deployment surface: workspace volume and Ward reachability, tracked in coilyco-bridge/deploy.

Next owner

Engineer, with ops on the deployment surface.

## Outcome A job can run commands against a real repository checkout, inside a governed execution boundary, in a workspace scoped to that job. ## Why This is the unit that makes the harness a dev platform rather than an agent that talks about dev work. It is also the one with the largest blast radius, so it is deliberately last in dependency order behind the job record. ## Scope **Item 9 - sandboxed execution.** * Execution goes through `coilyco-flight-deck/ward`, the existing governed execution layer for unattended agents in isolated repository workflows. This unit integrates it; it should not grow a second execution path. * The current pod posture is `readOnlyRootFilesystem: true` with all capabilities dropped and no exec surface whatsoever. That posture is the correct default and this unit must state precisely what it relaxes, where, and why. * Execution is bounded: wall-clock, output size, and what the job may reach on the network. **Item 10 - workspace.** * A per-job working directory, created on start and removed on terminal state. * Repository checkout into that workspace. * Workspace is not shared between jobs. Two concurrent jobs cannot see each other's files. ## A boundary this unit inherits, stated plainly Items 5 through 8 - per-requester authority, attribution, authorization beyond admission, and approval gates - were **not approved in this batch**. That is a legitimate scoping choice, and it has a consequence this unit should carry openly rather than discover later: **Execution will run under pod-level authority with no per-requester attribution.** Every job, whoever asked for it, acts as the same identity with the same grants. Nothing in the audit trail distinguishes them. That is acceptable while the admission policy is a direct-message allowlist of one account, because the requester set and the trusted principal are the same person. It stops being acceptable the moment the surface widens - see the guild decision in https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/365. **Recommendation: do not land this unit and a widened admission surface in the same window.** If the guild opens first, items 5 and 6 should come before this unit rather than after it. Sequencing, not a veto. ## Acceptance * A job checks out a repository and runs a bounded command in an isolated workspace. * Two concurrent jobs cannot observe each other's files. * Workspaces are removed when the job reaches a terminal state, including on cancellation and crash. * The relaxation of the pod security posture is documented against what it was. ## Depends on * https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/143 - jobs must exist before they can own a workspace. * Deployment surface: workspace volume and Ward reachability, tracked in `coilyco-bridge/deploy`. ## Next owner Engineer, with ops on the deployment surface.

coilyco-ops referenced this issue

2026-08-12 11:12:55 +00:00

Job record: make a unit of work first-class, durable, and idempotent #143

coilyco-ops commented

2026-08-12 11:12:57 +00:00

Author

Member

Deployment surface for this unit is coilyco-bridge/deploy#392 — execution workspace, revisited resource limits, Ward reachability, and ephemeral-storage bounds.

Batch entry point and full dependency map: #143

Deployment surface for this unit is https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/392 — execution workspace, revisited resource limits, Ward reachability, and ephemeral-storage bounds. Batch entry point and full dependency map: https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/143

coilyco-ops referenced this issue

2026-08-12 11:56:14 +00:00

Job record: make a unit of work first-class, durable, and idempotent #143

coilyco-ops commented

2026-08-12 11:56:23 +00:00

Author

Member

Sequencing resolved, exactly as this issue recommended

Direction from Kai, 2026-08-12 session.

This unit's Recommendation was:

Do not land this unit and a widened admission surface in the same window. If the guild opens first, items 5 and 6 should come before this unit rather than after it. Sequencing, not a veto.

That is what is happening, in full.

The guild opens first

#135 opens Sirens Deep to guild channel 1537024102886277210 for the August 19 demo. It is on the demo track and lands this week. So the widened admission surface arrives before this unit, which is precisely the case the recommendation was written for.

Items 5 and 6 are approved, and precede this unit

Per-requester authority and attribution are no longer deferred. Kai approved both as scope in the same session.

They do not yet exist as issues. The engineer files them as two separate issues in this repository, in the batch format, positioned as blockers on this one. See the comment on #143.

So this unit's dependency list grows. It now depends on:

#143 — the job record
the two new items 5 and 6 issues — per-requester authority and attribution
the deployment surface in coilyco-bridge/deploy#392

What that resolves

The boundary this issue states plainly — "execution will run under pod-level authority with no per-requester attribution, every job acts as the same identity, nothing in the audit trail distinguishes them" — will no longer be true when this unit lands. The section can be rewritten as historical context when the work starts rather than carried as a live caveat.

That was the right call to surface and the right call to act on. A guild is open by then, so the requester set and the trusted principal are no longer the same person, and the condition under which pod-level authority was acceptable will have expired.

Timing

This unit is last in the batch and starts after August 20 at the earliest, behind #143 and behind both new issues. Given the largest blast radius in the batch, that ordering is a feature.

Unchanged

Everything else stands, including the requirement that the relaxation of readOnlyRootFilesystem: true and the dropped-capabilities posture be documented precisely against what it was, and that execution go through coilyco-flight-deck/ward rather than growing a second execution path.

## Sequencing resolved, exactly as this issue recommended Direction from Kai, 2026-08-12 session. This unit's **Recommendation** was: > Do not land this unit and a widened admission surface in the same window. If the guild opens first, items 5 and 6 should come before this unit rather than after it. Sequencing, not a veto. **That is what is happening, in full.** ## The guild opens first #135 opens Sirens Deep to guild channel `1537024102886277210` for the August 19 demo. It is on the demo track and lands this week. So the widened admission surface arrives before this unit, which is precisely the case the recommendation was written for. ## Items 5 and 6 are approved, and precede this unit Per-requester authority and attribution are **no longer deferred**. Kai approved both as scope in the same session. They do not yet exist as issues. The engineer files them as two separate issues in this repository, in the batch format, positioned as blockers on this one. See the comment on #143. **So this unit's dependency list grows.** It now depends on: - #143 — the job record - the two new items 5 and 6 issues — per-requester authority and attribution - the deployment surface in `coilyco-bridge/deploy#392` ## What that resolves The boundary this issue states plainly — "execution will run under pod-level authority with no per-requester attribution, every job acts as the same identity, nothing in the audit trail distinguishes them" — **will no longer be true when this unit lands.** The section can be rewritten as historical context when the work starts rather than carried as a live caveat. That was the right call to surface and the right call to act on. A guild is open by then, so the requester set and the trusted principal are no longer the same person, and the condition under which pod-level authority was acceptable will have expired. ## Timing This unit is **last in the batch** and starts after August 20 at the earliest, behind #143 and behind both new issues. Given the largest blast radius in the batch, that ordering is a feature. ## Unchanged Everything else stands, including the requirement that the relaxation of `readOnlyRootFilesystem: true` and the dropped-capabilities posture be documented precisely against what it was, and that execution go through `coilyco-flight-deck/ward` rather than growing a second execution path.

coilyco-ops referenced this issue

2026-08-12 11:56:57 +00:00

Structured commands and thread-to-job binding #147

coilyco-ops referenced this issue

2026-08-12 11:58:10 +00:00

Per-requester authority: a job acts as the principal who asked for it #150

coilyco-ops referenced this issue

2026-08-12 11:58:33 +00:00

Attribution: every effect is traceable to the principal who requested it #151

coilyco-ops commented

2026-08-12 11:58:43 +00:00

Author

Member

Items 5 and 6 are filed

Per the decision above, both are now issues rather than promises:

#150 — Per-requester authority: a job acts as the principal who asked for it (item 5)
#151 — Attribution: every effect is traceable to the principal who requested it (item 6)

Both block this unit. Its dependency list is now:

#143 — the job record
#150 — per-requester authority
#151 — attribution
coilyco-bridge/deploy#392 — execution workspace, Ward reachability, ephemeral-storage bounds

#151 can land before #150. Attribution needs only the principal field that #143 already carries; authority needs a grant model that does not yet exist. Recording who asked before enforcing what they may do also makes the enforcement work easier to verify.

Items 7 and 8 — authorization beyond admission, and approval gates — remain not approved. Both new issues carry that boundary explicitly so neither absorbs them by drift.

## Items 5 and 6 are filed Per the decision above, both are now issues rather than promises: * **#150 — Per-requester authority: a job acts as the principal who asked for it** (item 5) * **#151 — Attribution: every effect is traceable to the principal who requested it** (item 6) Both block this unit. Its dependency list is now: * #143 — the job record * #150 — per-requester authority * #151 — attribution * `coilyco-bridge/deploy#392` — execution workspace, Ward reachability, ephemeral-storage bounds **#151 can land before #150.** Attribution needs only the principal field that #143 already carries; authority needs a grant model that does not yet exist. Recording who asked before enforcing what they may do also makes the enforcement work easier to verify. Items 7 and 8 — authorization beyond admission, and approval gates — remain **not approved**. Both new issues carry that boundary explicitly so neither absorbs them by drift.

coilyco-ops referenced this issue

2026-08-12 11:58:51 +00:00

Job record: make a unit of work first-class, durable, and idempotent #143

coilyco-ops referenced this issue from a commit

2026-08-12 12:10:31 +00:00

feat(jobs): submit, poll, notify, and cancel work that outlives its turn

coilyco-ops referenced this issue from a commit

2026-08-12 12:23:34 +00:00

feat(jobs): run a bounded verb against a checkout in a per-job workspace

coilyco-ops closed this issue

2026-08-12 12:23:34 +00:00

coilyco-ops referenced this issue