From ea013f46ba899a133e14750dc2fd7132da157d4e Mon Sep 17 00:00:00 2001 From: Robby Cochran Date: Thu, 18 Jun 2026 07:46:39 -0700 Subject: [PATCH 1/2] X-Smart-Branch-Parent: main From 374d5a9bf839de91ee098ccfeacba5c06e856fbb Mon Sep 17 00:00:00 2001 From: Robby Cochran Date: Thu, 18 Jun 2026 10:18:57 -0700 Subject: [PATCH 2/2] docs: expand Why this exists section in README Rewrite the motivation section to articulate the core design constraint: a developer harness that is not continuously tested in CI will silently break as upstream dependencies change. Add the local-to-automated path description showing how the same YAML config moves from laptop to OCP by changing one field. --- README.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index b8cb17c..959d614 100644 --- a/README.md +++ b/README.md @@ -50,9 +50,13 @@ To get results out: `--task` mode outputs to stdout, `openshell sandbox exec` pu ## Why this exists -[OpenShell](https://github.com/NVIDIA/OpenShell) is a sandbox management layer with deny-by-default L7 network policy, credential proxy, filesystem isolation, and inference routing. It is designed as a strict, secure base that supports other workflows. +[OpenShell](https://github.com/NVIDIA/OpenShell) provides a strict, secure sandbox runtime — deny-by-default L7 network policy, credential proxying, Landlock filesystem isolation, and inference routing. What it doesn't provide is the developer workflow layer on top: the config that wires up providers, the deployment abstraction that works the same locally and on a cluster, or the CI harness that catches breakage before developers hit it. -One YAML file defines the agent, providers, payloads, and policy and one command deploys it via Podman or remotely on Kubernetes. +Without a shared harness layer, every team building on OpenShell independently solves the same problems — writing shell scripts to register providers, hand-rolling container images, maintaining separate deployment procedures per environment. The configs diverge, the security posture varies, and nobody catches regressions until something breaks in production. + +**The core design constraint**: if the developer harness isn't running and live-tested in CI, the developer experience can't be maintained. OpenShell, agent CLIs, and provider APIs all change frequently — often multiple times per week. A harness that works today and isn't continuously validated will silently break. harness-openshell runs the full lifecycle (deploy gateway → register providers → create sandbox → run task → tear down) in CI on every change, across three deployment targets: local Podman, Kind, and OpenShift. + +**The path from local to automated**: a developer runs `harness apply --attach` for interactive work. When the workflow is ready for CI, they change `--attach` to `--task @skill.md` and `gateway: local-container` to `gateway: openshift`. Everything else stays the same. No rewriting, no separate deployment tooling. The harness YAML is the artifact — sharable, versionable, forkable. OpenShell's upstream direction is toward a [Kubernetes Operator](https://github.com/NVIDIA/OpenShell/issues/1719) where providers and sandboxes become CRDs and the gateway narrows to data-plane only. The harness explores what the workflow layer looks like above that with a developer mindset from local machine to cluster.