HarnessStatus is never populated: a Harness has no status subresource and status.capabilities is unreadable

[Rachael-Graham]

Disclosure: this issue was written by an AI agent (Claude) while checking which
Harness fields documentation can rely on, and reviewed by a human before filing.

Summary

HarnessStatus is declared in the API but nothing ever writes it. A Harness on a running
cluster has no status key at all, so kubectl get harness shows an empty READY column and
status.capabilities cannot be read by anyone.

Evidence

On a working cluster where AgentInstances on this Harness serve traffic normally:

$ kubectl get harness -A
NAMESPACE   NAME     READY   AGE
kagent      kagent           3h53m

$ kubectl get harness kagent -n kagent -o json | jq 'has("status")'
false

Not an empty object — the subresource is absent.

What is declared but unpopulated

// go/api/v1alpha3/harness_types.go:154-163, 211
// HarnessCapabilities records behavior proven for a pinned adapter and runtime.
type HarnessCapabilities struct {
	...
	NativeAgentTools bool `json:"nativeAgentTools"`
}
...
Capabilities *HarnessCapabilities `json:"capabilities,omitempty"`

grep -rn 'NativeAgentTools\|HarnessCapabilities' --include='*.go' go returns hits only in
harness_types.go and the generated zz_generated.deepcopy.go. No controller sets either.

By contrast AgentTemplate status is populated well — a per-harness conditions array with
Accepted, ResolvedRefs, Compatible, and Ready — so the gap is specific to Harness.

Why it matters

Two things readers and tooling would reasonably expect:

1. A Harness has no readable readiness. Whether its workload image, WorkerPool reference, and
   snapshot location are usable is only discoverable indirectly, by applying an AgentTemplate
   that the Harness admits and reading that object's conditions.
2. status.capabilities looks like the intended source of truth for which runtime supports
   which behaviour, so documentation is currently forced to hand-maintain a
   provider-and-runtime matrix that the API implies should be discoverable.

Expected

Either the Harness controller populates status — at minimum an Accepted condition, and
capabilities if it is meant to be authoritative — or the unpopulated fields are removed
from the public API so nothing appears readable when it is not.

Adjacent

An AgentTemplate that no Harness admits also gets no status.harnesses[] entry at all,
which combined with the absent Harness status leaves a missing
allowedAgentTemplates.selector label with no diagnostic on either object. The only signal
is kagent create agent-instance failing with FailedPrecondition: AgentTemplate and Harness do not have a ready prepared revision, which names neither the selector nor the
label. Happy to split that into its own issue if it is worth one.