Expose residue policy in compute steps

.github/workflows/build.yml

@@ -28,7 +28,7 @@ jobs:
           go env -w GONOSUMDB=github.com/GoCodeAlone/*
       - name: Install wfctl
         run: |
-          curl -fsSL -o wfctl https://github.com/GoCodeAlone/workflow/releases/download/v0.27.0/wfctl-linux-amd64
+          curl -fsSL -o wfctl https://github.com/GoCodeAlone/workflow/releases/download/v0.63.1/wfctl-linux-amd64
           chmod +x wfctl
           sudo mv wfctl /usr/local/bin/wfctl
       - name: Test
@@ -44,6 +44,6 @@ jobs:
       - name: Check workflow-compute provider alignment
         run: scripts/check-workflow-compute-alignment.sh "$GITHUB_WORKSPACE/workflow-compute"
       - name: Validate workflow config
-        run: wfctl validate workflow.yaml
+        run: wfctl validate --allow-no-entry-points workflow.yaml
       - name: Build with wfctl
         run: wfctl build --config workflow.yaml --no-push --tag ci

README.md

@@ -83,6 +83,15 @@ steps:
       timeout_seconds: 1800
       labels:
         app: example-api
+      residue_policy:
+        mode: session-bound
+        allowed_modes:
+          - isolated
+          - session-bound
+        session_key: ci-main
+        max_age_seconds: 1800
+        max_reuse_count: 3
+        wipe_on_failure: true
       workload:
         kind: container-build
         container_build:
@@ -102,6 +111,11 @@ steps:
       timeout: 30m
 ```
 
+`residue_policy` is optional task intent for short-lived workloads, useful for
+bounded CI dependency caches. The wfcompute provider runtime profile and network
+product must also allow the requested mode; core `workflow-compute` resolves the
+effective lease policy and enforces workspace reuse or isolation.
+
 For fanout work, use `step.compute_map` with a deterministic `tasks` list. The
 step submits every task, polls the core task/proof APIs, and stops the Workflow
 pipeline if any task fails, stalls, times out, or produces a non-accepted proof.
@@ -110,7 +124,7 @@ pipeline if any task fails, stalls, times out, or produces a non-accepted proof.
 
 ```sh
 GOWORK=off go test ./...
-wfctl validate workflow.yaml
+wfctl validate --allow-no-entry-points workflow.yaml
 GOWORK=off wfctl build --config workflow.yaml --no-push --tag local
 ```
 

SPEC.md

@@ -21,6 +21,7 @@ C10: Public client control-plane access ≠ provider/admin mutation ingress.
 C11: Plugin provider catalog details track `workflow-compute`'s typed `ProviderContract`, not a parallel plugin-local provider shape.
 C12: Provider-specific typed steps belong in the owning provider plugin, not this generic compute adapter.
 C13: Provider catalog entries are imported `workflow-compute` contracts; product/application assumptions belong in the calling workflow or provider plugin.
+C14: Task residue policy submitted by this plugin is customer intent only; `workflow-compute` owns provider/product authority resolution, policy hashing, lease enforcement, and residue cleanup.
 
 §I
 
@@ -59,6 +60,7 @@ V19: PR CI checks plugin provider catalog tests against current `GoCodeAlone/wor
 V20: manifest `stepTypes` exactly match runtime `StepTypes`
 V21: plugin step/CLI surfaces must not mention product-capture, BMW, edge lambda, edge CDN, or another provider-specific business domain
 V22: `compute.provider_catalog` accepts typed `protocol.ProviderContract` records from provider plugins without defining a parallel plugin-local provider schema
+V23: `step.compute_dispatch` and `step.compute_map` accept valid short-lived task `residue_policy`, reject malformed residue policy locally, and do not compute policy hashes or override provider/product authority
 
 §T
 
@@ -76,6 +78,7 @@ T10|x|document external Workflow client use cases and public client-surface boun
 T11|x|align provider catalog details with workflow-compute `ProviderContract` and gate drift in PR CI|C11,I.module,V19
 T12|x|remove provider-specific product-capture step/CLI/domain preview flattening from generic compute adapter|C12,I.step,V20,V21
 T13|x|keep provider catalog validation generic so external provider plugins can supply edge/product contracts without plugin-local provider schema|C13,I.module,V19,V22
+T14|x|submit optional short-lived task residue policy through dispatch/map steps without taking over core authority resolution|C14,I.step,V23
 
 §B
 

docs/plans/2026-05-24-residue-policy-plugin-surface-alignment.md

@@ -0,0 +1,32 @@
+# Residue Policy Plugin Surface Alignment
+
+### Alignment Report
+
+**Status:** PASS
+
+**Coverage:**
+
+| Design Requirement | Plan Task(s) | Status |
+|---|---|---|
+| Add optional `protocol.ResiduePolicy` to shared task config. | Task 1, Task 2 | Covered |
+| Validate malformed residue policy locally while leaving authority checks to core. | Task 1, Task 2 | Covered |
+| Copy task residue policy into submitted `protocol.Task`. | Task 1, Task 2 | Covered |
+| Support both dispatch and map steps through shared config. | Task 1, Task 2 | Covered |
+| Keep `compute.provider_catalog` typed as `[]protocol.ProviderContract`. | Task 1 | Covered |
+| Prove reusable residue is rejected for no-workspace runtime profiles. | Task 1 | Covered |
+| Update to a current `workflow-compute` dependency and keep provider alignment check. | Task 3, Task 4 | Covered |
+| Document optional usage and rollback by removing `residue_policy`. | Task 3 | Covered |
+| Avoid new scheduler, lease, worker, product schema, or long-lived service behavior. | Scope Manifest, Task 2, Task 3 | Covered |
+
+**Scope Check:**
+
+| Plan Task | Design Requirement | Status |
+|---|---|---|
+| Task 1 | Tests for dispatch/map pass-through and provider runtime contract validation. | Justified |
+| Task 2 | Shared task config validation and task submission pass-through. | Justified |
+| Task 3 | Dependency freshness, SPEC invariant, and README optional usage. | Justified |
+| Task 4 | Full verification, provider alignment, wfctl checks, and PR monitoring. | Justified |
+
+**Drift Items:** None.
+
+Manifest check: `plan-scope-check.sh --plan /Users/jon/workspace/workflow-plugin-compute/docs/plans/2026-05-24-residue-policy-plugin-surface.md` passed.

docs/plans/2026-05-24-residue-policy-plugin-surface-design-review.md

@@ -0,0 +1,48 @@
+# Residue Policy Plugin Surface Design Review
+
+### Adversarial Review Report
+
+**Phase:** design
+**Artifact:** docs/plans/2026-05-24-residue-policy-plugin-surface-design.md
+**Status:** PASS
+
+**Findings (Critical):**
+- None.
+
+**Findings (Important):**
+- None. Initial dependency-staleness concern was resolved in the design by
+  requiring a `workflow-compute` revision that includes the final residue
+  guardrails and by keeping the existing local provider-alignment check.
+
+**Findings (Minor):**
+- [YAGNI] Tests section: A service-only network-product rejection test would
+  imply this generic plugin owns product schemas, which conflicts with the
+  existing provider-catalog-only module boundary. Recommendation: keep plugin
+  tests focused on task pass-through and provider runtime contract validation.
+- [Rollback] Rollback mentions removing `residue_policy` from configs but does
+  not require a docs example. Recommendation: update README only with a small
+  example so rollback remains "remove the optional field."
+
+**Bug-class scan transcript:**
+
+| Class | Result | Note |
+|---|---|---|
+| Unstated assumptions | Clean | The design now states protocol authority, provider-contract input shape, task intent boundaries, strict decode behavior, and dependency availability. |
+| Repo-precedent conflicts | Clean | `AGENTS.md` and `SPEC.md` say this plugin translates Workflow schemas and must not own scheduler/provider semantics; the design keeps that boundary. |
+| YAGNI violations | Finding | Product/service rejection tests would exceed this plugin's module boundary; narrowed to provider runtime contract validation. |
+| Missing failure modes | Clean | Malformed residue config, stale dependency, and authority rejection are covered by plugin validation plus core validation. |
+| Security / privacy at architecture level | Clean | The design does not add secret surfaces or local execution; reusable residue authority remains in core. |
+| Rollback story | Finding | Rollback is additive and feasible, but docs should keep the optional field obvious. |
+| Simpler alternative not considered | Clean | Doing nothing and adding a separate step/module were considered and rejected. |
+| User-intent drift | Clean | The design supports provider/customer residue intent through plugin-first Workflow usage without changing long-lived service semantics. |
+
+**Options the author may not have considered:**
+1. Provider-catalog-only support: This would avoid task config changes, but it
+   leaves customers unable to request session/provider/worker-bound behavior
+   from Workflow steps.
+2. Plugin-local residue schema: This could give nicer YAML docs, but it would
+   duplicate core protocol validation and create drift risk.
+
+**Verdict reasoning:** PASS. The design is narrow, aligned with the existing
+plugin/core boundary, and security-sensitive enforcement stays in
+`workflow-compute`. Minor findings can be handled in the implementation plan.

docs/plans/2026-05-24-residue-policy-plugin-surface-design.md

@@ -0,0 +1,100 @@
+# Residue Policy Plugin Surface Design
+
+## Goal
+
+Expose `workflow-compute` short-lived residue policy through the generic
+Workflow compute plugin without moving scheduler, lease, worker, or provider
+authority semantics into the plugin.
+
+## Context
+
+`workflow-compute` now models residue policy on provider runtime profiles,
+network products, tasks, and leases. The generic plugin already accepts typed
+`protocol.ProviderContract` records in `compute.provider_catalog`, so provider
+and product policy can flow through that module without a plugin-local schema.
+The remaining gap is task intent: `step.compute_dispatch` and
+`step.compute_map` cannot currently submit a task-level `residue_policy`.
+
+## Approaches
+
+1. Add `protocol.ResiduePolicy` to the existing task config and pass it through
+   to `protocol.Task`.
+   This keeps the plugin thin, uses core validation types, and supports both
+   dispatch and map steps through the shared `taskConfig`.
+2. Add a new residue-specific step or module.
+   This would make residue policy visible, but it would create a second task
+   submission path and pressure the plugin toward scheduler policy ownership.
+3. Leave the plugin unchanged and rely on direct core API/CLI users for residue
+   policy.
+   This preserves current behavior but fails the Workflow/plugin-first use case.
+
+Use approach 1.
+
+## Design
+
+`taskConfig` gains an optional `residue_policy` field of type
+`protocol.ResiduePolicy`. `taskConfig.validate` calls
+`ResiduePolicy.Validate`, requiring explicit opt-in for `worker-bound` task
+requests and allowing `session-bound` only when `session_key` is present. The
+plugin does not calculate policy hashes or intersect provider/product allowed
+modes; `workflow-compute` still resolves and tightens the effective lease
+policy.
+
+`buildTask` copies the configured policy into the submitted `protocol.Task`.
+`step.compute_dispatch` and each `step.compute_map` task get the same behavior
+because they already share `taskConfig`.
+
+The plugin dependency should be updated to a `workflow-compute` revision that
+contains the final residue policy guardrails, including long-lived
+service-product rejection. The existing provider-alignment script keeps PR CI
+checking the plugin against a local checkout of current `workflow-compute`.
+
+`compute.provider_catalog` stays typed as `[]protocol.ProviderContract`.
+Provider runtime profile residue policy and no-workspace validation are already
+covered by `ProviderContract.Validate`, so the plugin only needs tests proving
+that catalog configs carrying residue policy validate and that no-workspace
+runtime profiles reject reusable residue.
+
+## Assumptions
+
+- `workflow-compute/pkg/protocol` is the stable source of truth for residue
+  field names and validation rules.
+- Provider plugins will emit `ProviderContract` and product definitions using
+  core protocol types rather than plugin-local YAML shortcuts.
+- Task-level residue policy is declarative intent; core remains responsible for
+  admission, policy intersection, hashing, and lease enforcement.
+- Existing Workflow strict decoding is sufficient for rejecting unknown residue
+  fields because the field uses the core struct.
+- A current `workflow-compute` module revision is available to the plugin CI via
+  private module auth or the existing local alignment checkout.
+
+## Self-Challenge
+
+- The lazy option is to do nothing because provider catalog already accepts
+  typed contracts. That misses task-level customer intent, which was part of the
+  residue model.
+- The fragile assumption is that provider/product definitions arrive as core
+  protocol records. If that changes, this plugin should still reject local
+  shortcuts rather than inventing a second schema.
+- The main partial-failure case is malformed residue policy reaching the core
+  API after Workflow validation. Early plugin validation catches local shape and
+  mode errors, while core still rejects authority violations.
+- A stale core dependency would make the plugin appear to support residue while
+  missing later guardrails. The plan must include a dependency update plus the
+  existing local alignment check.
+
+## Tests
+
+- Dispatch submits a `residue_policy` unchanged.
+- Map submits per-task residue policies unchanged.
+- Dispatch rejects unsupported residue modes and implicit `worker-bound`.
+- Provider catalog accepts runtime profiles with allowed residue modes and host
+  workspace support.
+- Provider catalog rejects reusable residue on no-workspace runtime profiles.
+
+## Rollback
+
+This is an additive config surface. Roll back by removing `residue_policy` from
+Workflow configs and reverting the plugin commit. Already submitted tasks keep
+their core task policy; operators can use the core residue wipe procedures if
+reusable workspace state was created.

docs/plans/2026-05-24-residue-policy-plugin-surface-plan-review.md

@@ -0,0 +1,50 @@
+# Residue Policy Plugin Surface Plan Review
+
+### Adversarial Review Report
+
+**Phase:** plan
+**Artifact:** docs/plans/2026-05-24-residue-policy-plugin-surface.md
+**Status:** PASS
+
+**Findings (Critical):**
+- None.
+
+**Findings (Important):**
+- None.
+
+**Findings (Minor):**
+- [Verification-class mismatch] Task 4 runs `wfctl build`, which can fail for
+  environment prerequisites outside the plugin. Recommendation: treat
+  documented environment failures as non-blocking only after checking the output
+  is not a plugin/config regression.
+- [Over-decomposition] Task 3 combines dependency, SPEC, and README edits.
+  Recommendation: acceptable for a one-PR plugin surface, but keep the commit
+  scoped and do not add examples beyond the optional residue block.
+
+**Bug-class scan transcript:**
+
+| Class | Result | Note |
+|---|---|---|
+| Unstated assumptions | Clean | The design and plan state core protocol authority and dependency availability. |
+| Repo-precedent conflicts | Clean | The plan follows `AGENTS.md` and `SPEC.md` by translating Workflow config only. |
+| YAGNI violations | Clean | No new module, product schema, or scheduler behavior is planned. |
+| Missing failure modes | Clean | Malformed residue, no-workspace reusable residue, stale core dependency, and CI failures have checks. |
+| Security / privacy at architecture level | Clean | No new secret/logging surface; residue authority remains in core. |
+| Rollback story | Clean | Runtime-affecting task steps include revert/remove-field rollback notes. |
+| Simpler alternative not considered | Clean | Doing nothing and a residue-specific step were considered in the design and rejected. |
+| User-intent drift | Clean | The plan keeps Workflow/plugin-first task intent support and avoids long-lived service changes. |
+| Over-decomposition / under-decomposition | Finding | Task 3 groups docs/dependency/SPEC edits; acceptable because they are small and coupled. |
+| Verification-class mismatch | Finding | `wfctl build` environment failures need output inspection before accepting as prerequisite-only. |
+| Hidden serial dependencies | Clean | Tasks are intentionally serial and touch shared files in a single PR. |
+| Missing rollback wiring | Clean | Rollback notes are present where the config surface and dependency can affect runtime behavior. |
+
+**Options the author may not have considered:**
+1. Split dependency update into a separate PR: cleaner rollback, but too much
+   process overhead for a small field pass-through that must compile against the
+   new protocol.
+2. Skip README changes: lower churn, but makes rollback and usage less obvious
+   for future plugin users.
+
+**Verdict reasoning:** PASS. The plan is narrow, test-first, and uses the
+existing provider-alignment script to catch protocol drift. Minor findings can
+be handled during execution.