Crate hatchery_harness_api 

Privacy-minimized read wire contract for the harness localhost host.

Each loopback TCP connection carries exactly one JSON request frame followed by \n. The caller must then half-close its write side; EOF is the request boundary and the host sends exactly one newline-terminated reply. A newline without the write half-close is incomplete and expires categorically as HarnessReadHostErrorV1::Deadline.

Structs

ActivityFactV1

BlockFactV1

One ObservationKindV1::ActionBlocked observation surfaced on the monitor wire – see SessionMonitorDetailV1::block_facts’s own doc comment for why this is its own list rather than folded into interaction_facts/process_facts. label is <authority slug>: <reason>, truncated to HARNESS_OBSERVATION_BLOCK_LABEL_MAX_BYTES by the producer – never the raw, up-to-1024-byte reason verbatim.

CallerRunV1

ContextSourceExclusionEntryV1

One ContextSourceExclusionV1 pinned to the run it was computed for – HarnessTaskLaunchOptionsV1::context_source_exclusions’s element type.

FileFactV1

HarnessAgentStreamChunkV1

One chunk of the outbound agent content stream – the operator-wire counterpart of gate4agent-node-protocol’s AgentStreamChunkV1, itself mirroring NodeEvent::TerminalFrame’s own precedent: its own subscription, its own type, no ObservationV1 resync promise (see HarnessOperatorAgentEventV1’s doc comment below). source_sequence orders chunks within one provider source the way ObservationV1::source_sequence orders observations.

HarnessAgentStreamInteractionOptionV1

One selectable answer to an InteractionPrompt chunk – an ACP permission option, named by the provider rather than invented here. Exact mirror of gate4agent-node-protocol’s own AgentStreamInteractionOptionV1.

HarnessAgentStreamNamedIdV1

One named catalog entry – a selectable session mode or model on the ModeCatalog/ModelCatalog chunk kinds. Exact mirror of gate4agent-node-protocol’s own AgentStreamNamedIdV1 (not a gate4agent_types type – it is minted on the node’s own wire contract, same duplication rationale as HarnessTerminalControlV1). id is what SetSessionMode/SetSessionModel take back.

HarnessArtifactRef

HarnessCancelTaskRequestV1

HarnessContextPackLineageV1

HarnessContextSourceSelectionV1

HarnessContinuationRef

HarnessCreateTaskRequestV1

HarnessDeliveryBundleDigestV1

HarnessDeliveryBundleIdV1

HarnessDeliveryBundleRevisionV1

HarnessDeliveryBundleSelectionV1

HarnessDeliveryBundleV1

HarnessDeliveryComponentCountV1

HarnessDeliveryManifestDigestV2

HarnessDeliveryRef

HarnessDispatchIntentV1

HarnessExecutionSpecId

HarnessGitCommitSummaryV1

HarnessGitCommitV1

HarnessGitObjectIdV1

HarnessGitStatusEntryV1

HarnessGitSummaryV1

HarnessGitWorktreeSnapshotV1

The other half of CreateWorktree’s reply. Mirrors the node’s own GitWorktreeSnapshot, minus lock_reason/prunable_reason (free-text reason strings the node’s own C2-facing mirror, C2GitWorktreeSnapshot, already drops – this wire never receives them to begin with).

HarnessGrantTargetV1

HarnessHostDirectoryEntryV1

One entry in a BrowseHostDirectories page. Mirrors the node’s own HostDirectoryEntry field-for-field; that type’s own constructor already rejects a non-UTF-8 path, so the node never actually produces the case HarnessHostPathV1 would reject here.

HarnessHostDirectoryListingV1

BrowseHostDirectories’s reply: mirrors the node’s own HostDirectoryListing field-for-field. Entries are deliberately not asserted to be sorted (unlike most other bounded collections on this wire, e.g. HarnessWorkspaceTreeEntryV1): a live directory listing has no such guarantee from the underlying filesystem, so imposing one here would reject a legitimate page.

HarnessHostPathV1

A bounded, UTF-8 host filesystem path: a workspace/worktree root, a worktree target, or a host-directory-browse cursor (directory/after/ parent/next_after). Mirrors the node’s own OpaqueHostPath narrowed to its UTF-8 representation only, the same way HarnessRepositoryPathV1 narrows the node’s dual-representation RepositoryPath – see repository_path_from_api/project_repository_path in hatchery-harness-service for that precedent: a genuinely non-UTF-8 host path from the node is a projection failure, never silently lossy-displayed. Validation intentionally stays as minimal as the node’s own validate_opaque_host_path (non-empty, bounded, no NUL byte): unlike a repository-relative path, an absolute host path legitimately contains backslashes, drive letters, and colons (Windows), so this type imposes no format assumptions beyond that.

HarnessIdempotencyRef

HarnessInlineRef

HarnessInlineRunSessionV1

HarnessIssuedExecutionSpecSummaryV1

HarnessLaunchPlanPageV1

HarnessLaunchPlanRefV1

HarnessLaunchPlanSummaryV1

HarnessManagedRunSessionV1

HarnessManagedWorktreeProfileOptionV1

HarnessMcpGrantMintV1

HarnessMoveTaskRequestV1

HarnessNativeSessionCatalogEntryV1

HarnessNativeSessionCatalogPageV1

HarnessNativeSessionCatalogSummaryV1

HarnessNativeSessionExternalGroupV1

HarnessNativeSessionIndexedV1

IndexNativeSession’s reply: echoes the committed selection alongside the resulting managed-session record, the same pairing HarnessNativeSessionPreviewedV1 uses for its own selection/payload echo.

HarnessNativeSessionPreviewMessageV1

HarnessNativeSessionPreviewV1

HarnessNativeSessionPreviewedV1

HarnessNativeSessionRouteV1

HarnessNativeSessionSelectionV1

HarnessNativeSessionsCatalogedV1

HarnessNativeSessionsPagedV1

HarnessNodeGitDiffV1

Node-scoped sibling of HarnessRunGitDiffV1.

HarnessNodeGitHistoryPageV1

Node-scoped sibling of HarnessRunGitHistoryPageV1.

HarnessNodeIncarnationV1

HarnessNodeWorkspaceDirectoryV1

Response payload for CreateNodeWorkspaceDirectory: the one node-scoped creation response (WorkspaceDirectoryCreated) that carries a WorkspaceEntry instead of a WorkspaceFileRead – HarnessNodeWorkspace FileV1 above covers WriteNodeWorkspaceFile/CreateNodeWorkspaceFile, both of which echo a file. Reuses HarnessWorkspaceTreeEntryV1, already the entry shape inside HarnessNodeWorkspaceInspectionV1.

HarnessNodeWorkspaceFileV1

Node-scoped sibling of HarnessRunWorkspaceFileV1.

HarnessNodeWorkspaceInspectionV1

Node-scoped sibling of HarnessRunWorkspaceInspectionV1.

HarnessNodeWorkspaceOriginV1

Node-scoped sibling of HarnessRunWorkspaceOriginV1: identifies a workspace read routed straight from a node/workspace pair, with no run binding to descend from.

HarnessOperationId

HarnessOperationLedgerEntryV1

D5, Slice D’s operator-side per-task operations ledger entry (HarnessOperatorRequestV1::TaskOperations / HarnessOperatorResponseV1::TaskOperations), one row per HarnessEngine::operations_for_task entry. Unlike RedactedOperationV1, actor here is the RAW HarnessActorV1 – the operator is already trusted with every other raw identity this wire exposes (session records, node/workspace ids, …), and this ledger is the audit trail the plan promises (“the operator’s ledger on T1 shows A’s run as the actor of both writes”). The agent side never gets this: g4a_tasks_get keeps RedactedTaskV1’s existing category-only exposure.

HarnessOperatorAuthorityV1

HarnessOperatorCredential

HarnessOperatorEnvelopeV1

HarnessOperatorIntentV1

HarnessOperatorRequestRefV1

HarnessOrdinaryLaunchPlanOptionV1

HarnessProviderConfigChoiceV1

Exact mirror of gate4agent_types::ProviderConfigChoice.

HarnessProviderConfigOptionV1

Exact mirror of gate4agent_types::ProviderConfigOption: the mechanism ACP uses to change model, reasoning effort, and similar settings. ConfigOptions always carries the FULL current set, never a delta – same contract as the source type’s own doc comment states for ProviderEvent::ConfigOptionsUpdated.

HarnessProviderSessionIdentityV1

Mirrors gate4agent_types::ProviderSessionIdentity: the caller-supplied reference IndexProviderSession binds a durable managed-session record to. Bounds match the node’s own PROVIDER_EVENT_ID_MAX_BYTES/ PROVIDER_SESSION_LOCATOR_MAX_BYTES (the node re-validates on its own terms regardless; this bound exists to reject an obviously-oversized request before it ever reaches C2).

HarnessReadCredential

HarnessReadEnvelopeV1

HarnessReadPermissionsV1

Independent object-level read scopes. A visible object’s references do not themselves authorize reading the referenced objects.

HarnessReceiptRef

HarnessReplaceTaskExecutionSpecRequestV1

HarnessReplaceTaskExecutionSpecRequestV2

HarnessReplaceTaskRequestV1

HarnessRepositoryPathV1

HarnessRequestDigest

HarnessResolvedContextPackReceiptV1

HarnessResultRef

HarnessRetryTaskRequestV1

HarnessReverseAttributionLinkV1

HarnessReverseAttributionV1

HarnessReverseAttributionWorkspaceV1

HarnessReviewedTaskLaunchSelectionV1

HarnessRevision

HarnessRunContextSourceObservationV1

HarnessRunContextTransferV1

HarnessRunContinuationTransferV1

HarnessRunCorrelationV1

HarnessRunDeliveryTransferV1

HarnessRunGitDiffV1

HarnessRunGitFactsV1

HarnessRunGitHistoryPageV1

HarnessRunId

HarnessRunIntentV1

HarnessRunTransferSummaryV1

HarnessRunWorkspaceFileV1

HarnessRunWorkspaceInspectionV1

HarnessRunWorkspaceOriginV1

HarnessRuntimeBundleReceiptV1

Mirror of gate4agent_node_protocol::ResolvedBundleReceipt.

HarnessRuntimeEnvironmentProfileReceiptV1

Mirror of gate4agent_node_protocol::ResolvedEnvironmentProfileReceipt.

HarnessRuntimeIdentityV1

HarnessRuntimeInventoryPageV1

HarnessRuntimeInventoryV1

HarnessRuntimeLaunchInventoryV1

Mirror of gate4agent_node_protocol::LaunchInventory.

HarnessRuntimeManagedSessionV1

HarnessRuntimeNodeInventoryV1

HarnessRuntimeSessionAddressV1

HarnessRuntimeSessionBindingV1

HarnessRuntimeSessionV1

HarnessRuntimeSpawnProfileSummaryV1

Mirror of gate4agent_node_protocol::SpawnProfileSummary.

HarnessRuntimeTerminalFrameV1

HarnessRuntimeTerminalPageV1

HarnessRuntimeTerminalSizeV1

HarnessRuntimeWorkspaceV1

HarnessScheduleNextRequestV1

HarnessScheduledLaunchRefV2

HarnessSelectorV1

HarnessSessionRecordPreviewedV1

PreviewSessionRecord’s reply: reuses HarnessNativeSessionPreviewV1 verbatim rather than defining a session-record-specific preview shape – the node’s own SessionRecordPreview and NativeSessionPreview are the same type (pub type NativeSessionPreview = SessionRecordPreview; in gate4agent-node-protocol), so the wire mirrors that identity instead of inventing a duplicate.

HarnessSessionRecordResumedV1

ResumeSessionRecord’s reply: unlike ResumeSession (ack-only, no address – see that request variant’s doc comment), the node returns the freshly spawned session’s address synchronously alongside the updated record, and this wire mirrors that exactly.

HarnessStartTaskRequestV1

HarnessStartTaskRequestV2

HarnessTaskExecutionSpecInputV1

HarnessTaskExecutionSpecV1

HarnessTaskExecutionSpecV2

HarnessTaskId

HarnessTaskLaunchIssuanceId

HarnessTaskLaunchIssuanceRefV1

HarnessTaskLaunchOptionsV1

HarnessTaskStartOutcomeV1

HarnessWorkspaceFileRevisionV1

HarnessWorkspaceInspectionTruncationV1

Additive mirror of gate4agent_node_protocol::WorkspaceInspectionTruncationV1 carried onto both HarnessRunWorkspaceInspectionV1 and HarnessNodeWorkspaceInspectionV1 — see that type for field meaning. Kept as this crate’s own type (rather than reused directly) to match every other leaf field on these two structs, which project into Harness*V1 types rather than exposing node-protocol/c2-protocol types on the operator-facing API surface.

HarnessWorkspaceSnapshotV1

RegisterWorkspace/CreateStandaloneWorkspace’s reply, and half of CreateWorktree’s. A deliberately narrowed projection of the node’s own WorkspaceSnapshot: sessions is dropped (redundant with the runtime inventory, which every roster-affecting resource mutation already invalidates on success – see HarnessOperatorRequestV1::RegisterWorkspace’s doc comment) and managed_worktree_profiles is dropped (SpawnManagedWorktree has no typed operator verb – see that request variant’s own doc comment for why – so a profile-catalog listing here would serve no reachable caller). workspace_id stays a bounded opaque string rather than a typed selector, matching every other node-scoped workspace id on this wire (HarnessNodeWorkspaceOriginV1.workspace_id, etc).

HarnessWorkspaceTreeEntryV1

InteractionFactV1

MonitorFeatureStatesV1

OperatorGateOptionV1

Exact mirror of gate4agent_types::OperatorGateOption.

OperatorGateStateV1

Exact mirror of gate4agent_types::OperatorGateState: this crate has no dependency on gate4agent-types (see the doc comment on HarnessTerminalControlV1), so the node’s gate classification is duplicated here as its own closed wire shape rather than imported. hatchery-harness-service is the single place that maps one into the other (map_operator_gate), so a field added to one side without the other fails to compile there.

RedactedOperationV1

RedactedRunIntentV1

RedactedRunV1

RedactedTaskV1

RunPageV1

SessionContextV1

SessionGrantId

SessionMonitorDetailV1

SessionMonitorHistoryV1

SessionMonitorV1

TaskPageV1

TimelineEntryV1

TimelinePageV1

TodoFactV1

Enums

ActivityClassV1

ActivityStateV1

BlockStateV1

A single, always-terminal variant today (paralleling FileActionV1:: Changed) – kept as its own enum rather than a bare unit field so a future, more granular block state has somewhere to land without another wire shape change.

ContextSourceExclusionV1

Names, with its compared inputs, the exact reason context_source_option (hatchery-harness-service::runtime) declined to surface a run as a context_sources candidate. Instrumentation only, never a policy decision – the admission logic itself is unchanged by this type’s existence; it only makes an already-silent exclusion observable from launch-options and the harness’s own logs (context source excluded). One variant per early exit in that function, Live and Durable branches alike; a Live-branch-only or Durable-branch-only condition says so in its own doc comment.

FeatureObservationStateV1

FileActionV1

HarnessActorV1

HarnessAgentStreamChunkKindV1

The kind of a single HarnessAgentStreamChunkV1 – content the operator needs to act on a running ACP session: what the agent is saying, a pending interaction it needs answered, and the catalogs the three ACP setter verbs (SetSessionMode, SetSessionConfigOption, SetSessionModel) operate over. Exact mirror of gate4agent-node-protocol’s own AgentStreamChunkKindV1, which itself mirrors gate4agent_types::ProviderEvent’s content variants deliberately, in contrast to the collapsed ObservationKindV1 telemetry stream, which carries none of it (docs/gate4agent/plans/gate4agent-acp-control-plane-on-the-wire-2026-09-02.md §3-4).

HarnessApprovalLevelV1

Wire mirror of gate4agent_types::ApprovalLevel – this crate has no dependency on gate4agent-types (see the module doc: a bounded, privacy-minimized domain contract, not a re-export surface), so the four levels are named again here rather than imported. Keep the variant set and the FullAuto default in exact lockstep with ApprovalLevel’s own; the two are converted between at the one boundary that links both crates (hatchery-harness-service), never compared or serialized against each other directly.

HarnessBlockAuthorityV1

Exact mirror of hatchery_observation_protocol::BlockAuthorityV1: this crate has no dependency on gate4agent-observation-protocol (see the doc comment on HarnessTerminalControlV1), so the WHO/WHAT-blocked-it vocabulary HarnessAgentStreamChunkKindV1::Blocked carries is duplicated here as its own closed wire enum rather than imported, the same way HarnessProviderInteractionKindV1 mirrors gate4agent_types:: ProviderInteractionKind.

HarnessContextSourceAvailabilityV1

HarnessContinuationOutcomeUnknownReasonV1

HarnessContinuationStateV1

HarnessDeliveryComponentKindV1

HarnessDeliveryStateV1

HarnessEntityReadScopeV1

Entity-local read authority rooted at the grant’s actor run.

HarnessExecutionModeV1

HarnessExpectedExecutionSpecRevisionV1

HarnessFailureCategoryV1

HarnessGitDiffModeV1

HarnessGitSignatureStatusV1

HarnessGitStatusCodeV1

HarnessLaunchAuthorityRefV1

HarnessManagedWorktreeRetentionV1

HarnessMonitoringVisibilityV1

HarnessNativeSessionCatalogScopeV1

HarnessNativeSessionCatalogWindowV1

HarnessNativeSessionExternalGroupKindV1

HarnessNativeSessionPreviewRoleV1

HarnessOperationKindV1

HarnessOperationStateV1

HarnessOperatorActionV1

HarnessOperatorAgentEventV1

Long-lived, server-push counterpart to a SubscribeAgentStream connection – see HarnessOperatorEventV1’s own doc comment for the shared framing this also uses. Deliberately its own type, not a variant of HarnessOperatorEventV1 and not a variant of HarnessOperatorTerminalEventV1 either, for two separate reasons this stream’s overflow story below has to hold at once:

HarnessOperatorApiError

HarnessOperatorEventV1

Long-lived, server-push counterpart to HarnessOperatorReplyV1. A SubscribeEvents connection stops replying with a single frame and instead writes one of these, newline-terminated, per change – see the module doc for the framing this switches the connection into. sequence is a per-subscription monotonic counter the host mints for that one connection alone; it never resets, including across a Lagged/SnapshotBaseline pair, so a client can detect a gap without cross-referencing wall time. An auth failure or an over-limit subscribe never reaches this type at all – both still use the ordinary single-frame HarnessOperatorReplyV1::Error before the connection closes, since neither one ever admits a subscription in the first place.

HarnessOperatorHostErrorV1

HarnessOperatorMutationOutcomeV1

HarnessOperatorReplyV1

HarnessOperatorRequestV1

HarnessOperatorResponseV1

HarnessOperatorTerminalEventV1

Long-lived, server-push counterpart to a SubscribeTerminal connection – see HarnessOperatorEventV1’s own doc comment for the shared framing this also uses. Deliberately its own type, not a variant of HarnessOperatorEventV1: that type’s Lagged/SnapshotBaseline pair promises a full task/run/node resync on overflow, which is both wrong for a terminal frame (there is no “task/run/node” to resync, only a screen that is already self-contained) and unaffordable at terminal-frame volume (see TerminalSubscriberRegistry’s own doc comment for the coalescing discipline this type’s coalesced_since_last field reports on).

HarnessOutcomeUnknownReasonV1

HarnessProviderConfigOptionKindV1

Exact mirror of gate4agent_types::ProviderConfigOptionKind.

HarnessProviderInteractionKindV1

Exact mirror of gate4agent_types::ProviderInteractionKind: this crate has no dependency on gate4agent-types (see the doc comment on HarnessTerminalControlV1), so the ACP interaction classification the node resolves a correlation_id against is duplicated here as its own closed wire enum, the same way HarnessAgentStreamChunkKindV1:: InteractionPrompt carries it on the outbound side.

HarnessProviderInteractionResponseV1

Exact mirror of gate4agent_types::ProviderInteractionResponse: this crate has no dependency on gate4agent-types (see the doc comment on HarnessTerminalControlV1), so ResolveInteraction’s answer payload is duplicated here as its own closed wire enum rather than imported. Unlike the source type’s own validate_for, validate() below does not check Answer/ApproveOnce/Deny against the live interaction’s own HarnessProviderInteractionKindV1 (Approval vs Question) – that check needs the interaction the node is holding under correlation_id and stays the node’s job, not this wire’s, the same way WriteSessionInput never checks that a PTY exists before sending. It bounds Answer { text } to HARNESS_ACP_INTERACTION_RESPONSE_MAX_BYTES and rejects unsafe control bytes, but not emptiness: the source type’s EmptyAnswer rule applies only when the interaction turns out to be a Question, which this wire does not know either.

HarnessProviderSessionKeyV1

Mirrors gate4agent_types::ProviderSessionKey exactly, for the same reason HarnessTerminalControlV1 duplicates TerminalControl rather than importing it – see that type’s own doc comment.

HarnessReadApiError

HarnessReadHostErrorV1

HarnessReadReplyV1

HarnessReadRequestV1

HarnessReadResponseV1

HarnessReconciliationOutcomeV1

HarnessResultDispositionV1

HarnessReverseAttributionBindingV1

HarnessReverseAttributionOutcomeV1

HarnessReverseAttributionRelationV1

HarnessReverseAttributionSubjectV1

HarnessReviewedWorktreeSelectionV1

HarnessRunCorrelationAvailabilityV1

HarnessRunFinishOutcomeV1

The two, and only two, outcomes g4a_run_finish accepts (measured 2026-09-09: the agent-facing surface has no verb a session can use to report its own work finished, so nothing it does ever reaches Done – see this type’s own call site, HarnessReadRequestV1::RunFinish, for the full account). Done and Failed name a definitive self-report, never a partial or in-progress state – there is no third value, by design: a session is either closing its own run as succeeded or as failed, not asking for anything in between.

HarnessRunFinishResultV1

The outcome of one g4a_run_finish call: resolves the caller’s OWN run from its grant binding (actor_run_id) – there is no run-id argument, so a session can never finish another session’s run. Finished names the run/task pair commit_lifecycle_projection (gate4agent-harness- service) actually transitioned and the outcome it recorded; task_id is the run’s own task, landed in Review (never Done – the review gate a session cannot skip) for done, or in Failed for failed. AlreadyFinished is the same “named refusal, never a silent no-op” discipline HarnessTaskMoveResultV1::RevisionConflict established for g4a_task_move: a second g4a_run_finish call against a run that is no longer Running/Waiting is refused by name, carrying the lifecycle it actually found, rather than answering with the same Finished shape a first, effective call gets.

HarnessRunLifecycleV1

HarnessRunSessionViewV1

HarnessRunWorktreeViewV1

HarnessRuntimeManagedModeV1

HarnessRuntimeManagedStateV1

HarnessRuntimeMouseProtocolEncodingV1

HarnessRuntimeSessionStatusV1

HarnessRuntimeTransportV1

HarnessScheduleOutcomeV1

HarnessSessionTaskTargetV1

Mirrors the node’s own SessionTaskTargetV1 shape exactly (New starts a fresh correlation, Existing binds to a caller-named task, Clear removes the binding). The node’s task_id there is its own local identifier space (format task-<24 lowercase hex>, unrelated to this crate’s HarnessTaskId despite the similar name – the node layer has no dependency on hatchery-harness-protocol and never mints one from a HarnessTaskId), so task_id here stays a bounded opaque string rather than the typed HarnessTaskId: the harness-service boundary parses and validates it against the node’s own format when building the C2 request.

HarnessTaskCreateResultV1

The outcome of one g4a_task_create call (D5, Slice D): an agent creates a task only under a parent already inside its own subtree (the caller’s own task by default – the tool’s contract), never system-wide the way the operator’s own HarnessCreateTaskRequestV1 can. Created names the minted id and its first revision; every other variant is a named refusal, never prose: each refusal is its own variant with its own typed fields rather than one Refused { reason } catch-all. TitleInvalid / BodyInvalid / DependenciesInvalid carry why – the underlying HarnessValidationError’s own Display text for InvalidTitle / InvalidBody / (SelfLink, CollectionTooLarge, or CollectionNotCanonical on dependencies) respectively, verbatim.

HarnessTaskMoveResultV1

The outcome of one g4a_task_move call (D5, Slice D): restricted to a task inside the caller’s own subtree, and never the task that governs the caller’s own run – a session never moves the task its own run is attributed to (scope discipline: an agent narrates its own subtree, it does not narrate itself). Moved names the resulting revision and both endpoints of the transition; every other variant is a named refusal in the same style HarnessTaskCreateResultV1 establishes. IllegalTransition answers to the same shape of rule the operator’s own validate_operator_move (hatchery-harness-service) enforces – from != to, no move out of a terminal state, Done only from Review – without duplicating that function here: the service applies its own agent-scoped rule and reports the two states it rejected.

HarnessTaskReviewPolicyV1

HarnessTaskStateV1

HarnessTerminalControlV1

Exact mirror of gate4agent_types::TerminalControl: this crate has no dependency on gate4agent-types (see the doc comment on HARNESS_SESSION_BYTES_MAX_BYTES), so ControlSession’s special-key payload is duplicated here as its own closed wire enum rather than imported. The variant set and names are kept in lockstep by hand – hatchery-harness-service’s c2::map_terminal_control is the single place that converts one into the other, so a variant added to one side without the other fails to compile there. No validate() method: unlike a bounded string or byte vector, a closed enum’s own deserialization is already the bound – an unrecognized variant name is rejected before this type is ever constructed.

HarnessValidationError

HarnessWorkspaceEntryKindV1

HarnessWorkspaceFileContentV1

HarnessWorktreeIntentV1

HarnessWorktreeServiceModeV1

Mirrors the node’s own WorktreeServiceMode.

InteractionClassV1

InteractionStateV1

ObservationEvidenceV1

OperatorGateInputV1

Exact mirror of gate4agent_types::OperatorGateInput.

OperatorGateKindV1

Exact mirror of gate4agent_types::OperatorGateKind.

OperatorGateOptionSemanticsV1

Exact mirror of gate4agent_types::OperatorGateOptionSemantics.

OperatorGateSubjectV1

Exact mirror of gate4agent_types::OperatorGateSubject.

ProjectionAvailabilityV1

ProjectionFreshnessV1

PtyScreenStateV1

Exact mirror of gate4agent_types::PtyScreenState: this crate has no dependency on gate4agent-types (see the doc comment on HarnessTerminalControlV1), so the node’s screen-content classification is duplicated here as its own closed wire enum rather than imported. hatchery-harness-service is the single place that maps one into the other, so a variant added to one side without the other fails to compile there.

RedactedBindingStateV1

RedactedWorktreeIntentV1

TaskCreatorCategoryV1

TimelineCategoryV1

TimelineStateV1

TodoStateV1

Constants

BUILD_STAMP

The harness operator wire is a loopback protocol between processes built from the same tree and rolled together (hatchery-harness and its two clients, hatchery-tui / hatchery-tui-light, via hatchery-harness-client). There is exactly one peer shape at a time – no peer that cannot be rebuilt exists – so the envelope now checks BUILD_STAMP for exact equality instead of a hand-typed version counter: BUILD_STAMP is a content hash of the working tree computed at compile time (see gate4agent-build-stamp), so any wire-shape change anywhere in the co-built tree moves it automatically, and a peer built from a byte-identical checkout always matches. An additive read-wire field still just needs #[serde(default)], same as before – nothing about that discipline changes. A persisted format version (a checkpoint, database schema, or any other record that must survive forward migration across releases) is a different thing entirely and keeps its own explicit, hand-bumped integer.

CONTEXT_SOURCE_EXCLUSION_KNOWN_INCARNATIONS_MAX

Bounds ContextSourceExclusionV1::NodeIncarnationUnknown’s own known_incarnations list – the incarnation(s) the runtime inventory currently holds for the excluded run’s node_id.

HARNESS_ACP_INTERACTION_RESPONSE_MAX_BYTES

HARNESS_AGENT_STREAM_CATALOG_ENTRIES_MAX

HARNESS_AGENT_STREAM_ID_MAX_BYTES

HARNESS_AGENT_STREAM_INTERACTION_OPTIONS_MAX

HARNESS_AGENT_STREAM_SUBSCRIPTION_SESSIONS_MAX

HARNESS_AGENT_STREAM_TEXT_MAX_BYTES

HARNESS_ARTIFACTS_MAX

HARNESS_BODY_MAX_BYTES

HARNESS_CHILD_COUNT_MAX

HARNESS_CHILD_DEPTH_MAX

HARNESS_CONTEXT_PACK_MAX_BYTES

HARNESS_CONTEXT_PACK_RETAINED_MESSAGES_MAX

HARNESS_CONTEXT_SOURCE_EXCLUSIONS_MAX

Bounds HarnessTaskLaunchOptionsV1::context_source_exclusions – a diagnostic dump of every run context_source_option declined to surface, not an operator-facing selection page, so it gets its own smaller ceiling rather than reusing HARNESS_TASK_LAUNCH_OPTIONS_MAX.

HARNESS_DEPENDENCIES_MAX

HARNESS_ENTITY_PAGE_LIMIT_MAX

HARNESS_GATE_OPTIONS_MAX

Mirrors gate4agent_types::OPERATOR_GATE_OPTIONS_MAX.

HARNESS_GATE_OPTION_TEXT_MAX_BYTES

Mirrors gate4agent_types::OPERATOR_GATE_OPTION_TEXT_MAX_BYTES.

HARNESS_GATE_PATH_MAX_BYTES

Mirrors gate4agent_types::OPERATOR_GATE_PATH_MAX_BYTES.

HARNESS_GIT_COMMIT_PARENTS_MAX

HARNESS_GIT_DIFF_MAX_BYTES

HARNESS_GIT_HISTORY_LIMIT_MAX

HARNESS_GIT_IDENTITY_MAX_BYTES

HARNESS_GIT_RECENT_COMMITS_MAX

HARNESS_GIT_SIGNER_MAX_BYTES

HARNESS_GIT_STATUS_ENTRIES_MAX

HARNESS_GIT_SUMMARY_MAX_BYTES

HARNESS_GIT_TIMESTAMP_MAX_BYTES

HARNESS_HOST_DIRECTORY_DISPLAY_NAME_MAX_BYTES

HARNESS_HOST_DIRECTORY_ENTRIES_MAX

HARNESS_HOST_PATH_MAX_BYTES

HARNESS_LAUNCH_PLAN_PAGE_LIMIT_MAX

HARNESS_LINKS_MAX

HARNESS_MCP_AUDIENCE

Credential audience for harness MCP read grants.

HARNESS_MONITOR_FACTS_MAX

HARNESS_NATIVE_SESSION_CATALOG_LIMIT_MAX

HARNESS_NATIVE_SESSION_PREVIEW_MESSAGE_LIMIT_MAX

HARNESS_NATIVE_SESSION_PREVIEW_TEXT_MAX_BYTES

HARNESS_OBSERVATION_BLOCK_LABEL_MAX_BYTES

Max bytes for BlockFactV1::label (<authority slug>: <reason>, producer-truncated to fit) – sized like HARNESS_OBSERVATION_TODO_TEXT_MAX_BYTES rather than HARNESS_OBSERVATION_LABEL_MAX_BYTES: a block’s reason is verbatim provider/gate prose, bounded at 1024 bytes where it is minted (see hatchery_observation_protocol::OBSERVATION_ACTION_BLOCKED_REASON_MAX_BYTES), not a short class slug like “bash”/“editor” the 64-byte activity-label bound was sized for.

HARNESS_OBSERVATION_LABEL_MAX_BYTES

HARNESS_OBSERVATION_PATH_MAX_BYTES

HARNESS_OBSERVATION_TODO_TEXT_MAX_BYTES

HARNESS_OPERATOR_CREDENTIAL_MAX_BYTES

HARNESS_OPERATOR_REQUEST_MAX_BYTES

HARNESS_OPERATOR_RESPONSE_MAX_BYTES

HARNESS_PROVIDER_SESSION_ID_MAX_BYTES

HARNESS_PROVIDER_SESSION_TRANSCRIPT_PATH_MAX_BYTES

HARNESS_READ_CREDENTIAL_MAX_BYTES

HARNESS_READ_LIMIT_MAX

HARNESS_READ_REQUEST_MAX_BYTES

HARNESS_READ_RESPONSE_MAX_BYTES

HARNESS_READ_TOOL_IDS

HARNESS_REPOSITORY_PATH_MAX_BYTES

HARNESS_RESULTS_MAX

HARNESS_REVERSE_ATTRIBUTION_LINKS_MAX

HARNESS_RUNTIME_INVENTORY_PAGE_LIMIT_MAX

HARNESS_RUNTIME_LAUNCH_BUNDLES_MAX

HARNESS_RUNTIME_SPAWN_PROFILES_MAX

HARNESS_RUN_GIT_PATH_MAX_BYTES

HARNESS_SCREEN_STATE_GATE_MAX_BYTES

Mirrors gate4agent_types::PTY_SCREEN_GATE_NAME_MAX_BYTES, the bound on Failing’s reason.

HARNESS_SCREEN_STATE_PROCESS_MAX_BYTES

Mirrors gate4agent_types::FOREGROUND_PROCESS_NAME_MAX_BYTES, the bound on PtyScreenStateV1::NotAgent’s observed_process. Hand-kept in step with the source constant for the same reason the enum itself is hand-duplicated below.

HARNESS_SESSION_BYTES_MAX_BYTES

HARNESS_SESSION_INPUT_MAX_BYTES

HARNESS_SESSION_RECORD_DISPLAY_NAME_MAX_BYTES

HARNESS_SESSION_RECORD_TASK_ID_MAX_BYTES

HARNESS_TASK_LAUNCH_OPTIONS_MAX

HARNESS_TERMINAL_FRAME_MAX_BYTES

HARNESS_TERMINAL_PAGE_LIMIT_MAX

HARNESS_TERMINAL_SCROLLBACK_LINES_MAX

HARNESS_TERMINAL_SUBSCRIPTION_SESSIONS_MAX

HARNESS_TIMELINE_PAGE_LIMIT_MAX

HARNESS_TITLE_MAX_BYTES

HARNESS_WORKSPACE_FILE_MAX_BYTES

HARNESS_WORKSPACE_TREE_ENTRIES_MAX

HARNESS_WRITE_TOOL_IDS

Slice D’s g4a_task_create/g4a_task_move (D5) and S10’s g4a_run_finish. Kept separate from HARNESS_READ_TOOL_IDS rather than folded into it – that array’s own test (all_eight_tool_schemas_are_stable_and_closed) pins it as exactly the eight read-only tools zipped in tool_definitions()’s declared order. g4a_task_create/g4a_task_move are gated by grant.task_permissions.create/.mutate respectively. g4a_run_finish is the one member of this array gated by no grant permission at all (expected_allowed_tool_ids carries it unconditionally, the same way it carries g4a_context_get out of HARNESS_READ_TOOL_IDS) – every session needs the ability to report its own work finished regardless of what else its grant allows. D7: this array, and HARNESS_READ_TOOL_IDS, are the only two names tools/call ever admits; ResolveInteraction (or any other name) is refused by name regardless of what a grant’s allowed_tool_ids claims.