refactor(policy)!: remove deprecated NetworkBinary.harness

[drew]

Description

Remove the deprecated and ignored NetworkBinary.harness protobuf field during the coordinated 0.1.0 breaking-change window.

The field is declared as:

• message: openshell.sandbox.v1.NetworkBinary
• field: harness
• tag: 2

Reserve both the numeric tag and field name after removal.

Context

The harness concept has been removed and the public protobuf comment says the field is ignored. Compatibility conversions and tests still carry the field through parts of the provider and policy code. Retaining an ignored security-policy field misleads clients and preserves dead generated SDK surface.

This is the field identified by the #2565 audit; it is NetworkBinary.harness, not a field directly on SandboxPolicy.

Related: #2565. Source audit: https://gist.github.com/mrunalp/e80942c1544a0225ee588796a41ab30b.

Definition of Done

• Remove NetworkBinary.harness from proto/sandbox.proto.
• Add reserved 2; and reserved "harness"; to NetworkBinary.
• Remove provider-profile, policy-merge, serialization, conversion, and test logic that reads or writes the deprecated bit.
• Regenerate or update all SDK bindings and fixtures.
• Reject or clearly migrate any legacy user-facing YAML/profile representation that still supplies harness.
• Confirm persisted records containing tag 2 continue to decode safely with the field ignored as unknown.
• Document the removal in the 0.1.0 migration notes.
• Run the relevant policy, provider, SDK, and compatibility tests.

Agent Investigation

The field remains at proto/sandbox.proto in NetworkBinary. References remain in provider-profile and policy merge/conversion code even though the proto documents the field as ignored.

[varshaprasad96]

📋 triage-agent

Triage Assessment

Classification: validated-feature

Summary

The deprecated public field and dead generated SDK surface are confirmed on current main, and removing the field during the coordinated pre-0.1.0 breaking-change window is technically coherent. The field is not fully ignored internally, however: runtime code repurposes it as policy-advisor provenance in a security-sensitive SSRF approval flow. Removal must preserve that behavior through an internal representation and regression coverage.

Investigation

• proto/sandbox.proto declares NetworkBinary.harness as deprecated field 2, and generated Go protobuf bindings still expose it. Normal policy YAML accepts and discards the legacy key, while provider-profile YAML still serializes, deserializes, and converts it.
• Policy merge, advisor proposal creation, and OPA projection read or write the bit as advisor_proposed provenance. Rego uses that provenance, together with endpoint provenance, when deciding whether an exact hostname may bypass the default private-address SSRF block.
• PR fix(sandbox): trust exact declared private endpoints #1560 introduced and tested this provenance behavior after identifying a possible SSRF bypass if advisor provenance is lost. A focused run of the existing supervisor-network regressions passed: both advisor-proposed binary and endpoint cases remain excluded from exact-declared-host trust.
• Persisted policy revisions and draft chunks contain protobuf-encoded policy/rule data. Reserving tag 2 and the name harness is the correct schema direction, but compatibility tests must confirm how legacy tag-2 payloads decode in each supported runtime and whether unknown bytes are dropped or preserved.
• The latest release is v0.0.116 and current main still contains the field, so there is no released fix. No duplicate or fixing PR was found. Stabilize public API, SDK, and extension contracts for 0.1.0 #2565 is the parent API-stabilization tracker, not a duplicate.
• No issue version was supplied, but current-source validation makes that non-blocking. The definition of done should explicitly require unchanged policy-advisor/SSRF behavior; the remaining provenance representation, legacy profile-YAML handling, and migration-note placement are implementation-time choices rather than triage blockers.

Impact Signals

• Affected users/scope: Direct protobuf/raw SDK consumers, provider-profile authors, persisted policy/draft compatibility, and policy-advisor/merge/runtime enforcement paths.
• Regression: No; this is longstanding deprecated surface and compatibility debt.
• Workaround: Consumers can ignore harness, but that does not remove the misleading generated API or legacy profile representation.
• Evidence quality: High; confirmed from current source, generated bindings, persistence paths, historical PR rationale, duplicate/release checks, and focused passing regression tests.

Human Decision Required

Decide whether OpenShell should address this issue. If yes, apply
state:accepted, associate it with a roadmap item, or do both, and decide
whether the work remains human-owned. Either action records acceptance;
roadmap placement additionally records sequencing.
To queue investigation or planning for an unattended agent, also apply
agent:plan-requested. You can instead directly ask an agent to use
create-spike or build-from-issue on this issue; the agent will warn about
missing expected workflow labels and continue without changing them. If no,
close it as not planned and record the rationale.

[varshaprasad96]

This is a straight-forward change. Will create a PR for this

[varshaprasad96]

🏗️ build-from-issue-agent

Implemented in #3222.

• Removed and reserved NetworkBinary.harness, then updated bindings and call sites.
• Preserved advisor provenance, including collision-safe rule separation and legacy stored-policy migration.
• Added migration documentation and regression coverage.
• Validation: pre-commit and Rust, Go, TypeScript, and Python suites pass.
• Docker E2E could not start because the local Docker daemon was unavailable.