Explore contextctl sync with Serverless Harness workloads

Goal

Determine how contextctl should move durable context into and out of Serverless Harness workloads, and validate the simplest useful end-to-end workflow.

Today Serverless Harness calls Context Service to allocate sandboxes and workspaces, while contextctl ctx sync transfers context directly to a Context Service PVC. The connection between a named context revision and the SH workload or run that consumes it is not yet explicit.

Questions to answer

• How does an SH workload declare the contexts it should mount?
• Should contexts be selected when creating a workload, starting a run, or both?
• Should contextctl continue targeting Context Service, target an SH workload abstraction, or support both?
• How are context name, revision, mount path, and read-only/read-write access represented?
• How do identity, namespace, and Context Service access grants map to SH users and workloads?
• Can a local context be pushed before a run, updated through background backup, and pulled after the run without exposing Kubernetes details?
• How should contextctl status or contextctl ctx graph show the SH workload consuming the context?

Validation scenario

Build a reproducible demo that:

1. Captures context from a local agent harness.
2. Pushes it with contextctl to a PVC-backed Context Service context.
3. Starts an SH workload or run that mounts and reads the context.
4. Produces an update or artifact from the SH workload.
5. Pulls the resulting context back locally and verifies it.

Use a realistic CSI-backed environment when practical, while keeping a Kind-compatible path for development.

Deliverables

• Document the current working flow and integration boundaries.
• Record any required SH API, Context Service API, and CLI changes.
• Propose a short, memorable CLI/API experience.
• Add or update a focused demo after the manual workflow succeeds.
• Open smaller implementation issues for agreed changes.

Acceptance criteria

• The local-to-SH-to-local scenario is demonstrated successfully or its concrete blockers are documented.
• The ownership boundary between SH, Context Service, and contextctl is explicit.
• Context attachment, access mode, revision, and lifecycle semantics are defined.
• A recommended UX is ready for implementation.

Start with the contextctl ctx sync command and the contextctl status or ctx graph entry points, then map the documented Context Service and Serverless Harness workflow. Validate the local-to-SH-to-local scenario in a CSI-backed environment with a Kind-compatible path. Done means the workflow or concrete blockers, ownership boundaries, lifecycle semantics, and focused demo are documented, with smaller implementation issues identified.