docs: explain context infrastructure

[moonlight16]

Summary

Follow up on the review feedback from #72 with CLI-specific guidance and a
clearer compatibility error.

• define the context command briefly and distinguish it from rossoctl
  configuration contexts and LLM context windows
• link help and the README to Rosso's canonical Context Service documentation
• provide a small command example and instructions for building the CLI from
  current source
• turn the common context list 404 from an older Rosso server into an
  actionable compatibility message referencing feat: integrate optional Context Service rossoctl#2392

The primary resource, storage, and lifecycle documentation remains in the Rosso
repository. rossoctl/rossoctl#2396 expands it with definitions of a workspace,
RWO/RWX access modes, and the current usage/deletion behavior.

Why context

The term describes context infrastructure made available to agents, including
workspaces, memory, knowledge, and artifacts. llm-context would be too narrow,
while a storage-specific name would couple the interface to today's PVC backend.

Compatibility

The commands require the server-side context resource API merged in
rossoctl/rossoctl#2392. No numbered Rosso release contains it yet, so the docs
identify the implementing PR rather than claiming an unavailable version.

Validation

• go test ./cmd -run 'TestContext|TestContexts'
• go test ./...
• make build
• git diff --check

[esnible]

When I list context infrastructure, will it tell me if the context infrastructure is in use?

When I delete a context infrastructure that is in-use, will it warn me?

How can I install Rossoctl from HEAD and try out the new commands?

[esnible]

Instead of documenting this concept here, refer in messages and docs to https://github.com/rossoctl/rossoctl/blob/main/docs/concepts/context-service.md or https://github.com/rossoctl/context-service

This repo is about a CLI, and shouldn't include what looks like primary documentation for the concept.

[moonlight16]

Agreed. I removed the primary concept document from this CLI repo. The README and command help now link to the canonical Rosso Context Service documentation, which is expanded in rossoctl/rossoctl#2396.

[esnible]

Having an example of how to create a ReadWriteOnce workspace is great, thanks! But I don't know what a ReadWriteOnce workspace is, and there is no docs for it at https://github.com/rossoctl/rossoctl/blob/main/docs/concepts/context-service.md . That document should define a "workspace".

Suggested change

	Create a private ReadWriteOnce workspace:
	Create a private ReadWriteOnce [workspace](https://github.com/rossoctl/rossoctl/blob/main/docs/concepts/context-service.md#workspace):

[moonlight16]

Added in rossoctl/rossoctl#2396 under the new Workspace section. It defines a workspace in filesystem terms and explains RWO and RWX. I also removed the inaccurate word private: RWO is a node-level mount constraint, not an access-control boundary.

[moonlight16]

Thanks, Ed. These questions exposed two gaps rather than merely documentation
wording.

context list currently reports provisioning/ready storage state, but it does
not report attached agents or an in-use count. Deletion also does not currently
warn or reject an attached context. Kubernetes PVC protection prevents the
underlying volume from being physically removed while a running Pod mounts it,
but the PVC may remain Terminating after deletion was accepted. I agree that
is not sufficient user-facing behavior.

I documented the current limitation and opened
context-service#2 to
design usage reporting plus a default 409 Conflict for in-use deletion. The
issue also calls out the distinction between currently mounted Pods and agent
specifications that still reference the context.

I moved the primary explanation into the canonical Rosso documentation in
rossoctl#2396. That PR defines a
workspace, explains RWO/RWX without assuming PVC familiarity, and corrects my
use of "private": RWO is a node-level mounting constraint, not a security
boundary or necessarily one-Pod access.

To try the CLI from current source:

git clone https://github.com/rossoctl/rossoctl-cli.git
cd rossoctl-cli
make build
./bin/rossoctl context --help

The commands require a Rosso server containing
rossoctl#2392. PR #73 now links
the canonical docs, includes the build instructions, and explains an older
server's 404 as a compatibility problem.