Crate hatchery_harness_protocol 

Bounded, privacy-minimized domain contract for the adjacent harness kernel.

Harness workflow state is explicit operator/agent intent. Monitoring facts are deliberately absent from this crate and cannot mutate task state.

Structs

HarnessArtifactRef

HarnessCancelTaskRequestV1

HarnessContextPackLineageV1

HarnessContextPermissionsV1

HarnessContextSourceSelectionV1

HarnessContinuationRef

HarnessContinuationV1

HarnessCreateTaskRequestV1

HarnessDeliveryBundleDigestV1

HarnessDeliveryBundleIdV1

HarnessDeliveryBundleRevisionV1

HarnessDeliveryBundleSelectionV1

HarnessDeliveryBundleV1

HarnessDeliveryComponentCountV1

HarnessDeliveryManifestDigestV2

HarnessDeliveryReceiptV1

HarnessDeliveryRef

HarnessDeliveryStageReceiptV1

HarnessDeliveryV1

HarnessDispatchIntentV1

HarnessExecutionSpecId

HarnessFailureV1

HarnessGrantTargetV1

HarnessIdempotencyRef

HarnessInlineRef

HarnessLaunchPlanRefV1

HarnessLaunchTargetSelectionV1

HarnessMoveTaskRequestV1

HarnessOperationId

HarnessOperationTimeoutsV1

HarnessOperationV1

HarnessOperatorAuthorityV1

HarnessReadPermissionsV1

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

HarnessReceiptRef

HarnessReplaceTaskExecutionSpecRequestV1

HarnessReplaceTaskRequestV1

HarnessRequestDigest

HarnessResolvedContextPackReceiptV1

HarnessResultRef

HarnessRetryTaskRequestV1

HarnessRevision

HarnessRunGitCommitSummaryV1

HarnessRunGitFactsV1

HarnessRunGitStatusEntryV1

HarnessRunGitSummaryV1

HarnessRunId

HarnessRunIntentV1

HarnessRunV1

HarnessRuntimeIdentityV1

HarnessScheduleNextRequestV1

HarnessScheduleRequestV1

HarnessScheduledLaunchRefV2

HarnessSelectorV1

HarnessSessionBindingV1

HarnessStartTaskRequestV1

HarnessTaskExecutionSpecInputV1

HarnessTaskExecutionSpecInputV2

HarnessTaskExecutionSpecV1

HarnessTaskExecutionSpecV2

HarnessTaskId

HarnessTaskLaunchIssuanceId

HarnessTaskLaunchIssuanceRefV1

HarnessTaskLaunchIssuanceV1

HarnessTaskPermissionsV1

create/mutate gate g4a_task_create/g4a_task_move (D5, Slice D: an agent’s own subtree only, never system-wide). #[serde(default)] on both so a grant persisted before Slice D decodes with create: false, mutate: false rather than failing closed on the whole record – the rule since 2026-09-05: a persisted type gains a field only behind #[serde(default)], proven by a test deserializing the pre-Slice-D shape (the same discipline read_permissions already established).

HarnessTaskStartOutcomeV1

HarnessTaskV1

SessionGrantId

SessionGrantV1

Enums

HarnessActorV1

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.

HarnessContextSourceAvailabilityV1

HarnessContinuationCleanupStateV1

HarnessContinuationOutcomeUnknownReasonV1

HarnessContinuationStateV1

HarnessDeliveryComponentKindV1

HarnessDeliveryStateV1

HarnessEntityReadScopeV1

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

HarnessExecutionModeV1

HarnessExpectedExecutionSpecRevisionV1

HarnessFailureCategoryV1

HarnessLaunchAuthorityRefV1

HarnessLaunchWorktreeSelectionV1

HarnessMonitoringVisibilityV1

HarnessOperationKindV1

HarnessOperationStateV1

HarnessOutcomeUnknownReasonV1

HarnessReconciliationOutcomeV1

HarnessResultDispositionV1

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.

HarnessRunGitFactsOutcomeV1

Terminal outcome of one background git-facts capture attempt against a run’s workspace. Unavailable folds every non-success cause (Node unreachable, route mismatch, deadline, rejection) into one permanent, non-retried terminal state — see the A3 design (§5.2/§9 risk 2).

HarnessRunGitStatusCodeV1

Mirror of harness-api’s HarnessGitStatusCodeV1 (field-for-field), kept as a narrow, intentional duplication forced by crate layering: hatchery-harness-protocol has no dependency on hatchery-harness-api.

HarnessRunLifecycleV1

HarnessScheduleOutcomeV1

HarnessSessionIdentityV1

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

HarnessTransferAuthorityRefV1

HarnessValidationError

HarnessWorktreeIntentV1

SessionGrantStateV1

Constants

HARNESS_ALLOWED_TARGETS_MAX

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_CONTINUATIONS_MAX

HARNESS_DELIVERIES_MAX

HARNESS_DELIVERY_COMPONENTS_MAX

HARNESS_DELIVERY_COMPONENT_KINDS_MAX

HARNESS_DELIVERY_RESOURCE_MAX_BYTES

HARNESS_DEPENDENCIES_MAX

HARNESS_LINKS_MAX

HARNESS_RESULTS_MAX

HARNESS_RUN_GIT_BRANCH_MAX_BYTES

HARNESS_RUN_GIT_PATH_MAX_BYTES

HARNESS_RUN_GIT_RECENT_COMMITS_MAX

HARNESS_RUN_GIT_STATUS_ENTRIES_MAX

HARNESS_RUN_GIT_SUMMARY_MAX_BYTES

HARNESS_SCHEDULER_SCAN_MAX

HARNESS_SELECTOR_MAX_BYTES

HARNESS_TASK_RESULT_WHY_MAX_BYTES

Bound on HarnessTaskCreateResultV1/HarnessTaskMoveResultV1’s own why fields (D5, Slice D). The value they carry is always a short, fixed-format HarnessValidationError Display rendering, never arbitrary caller-supplied prose, but this side still bounds it defensively – the same 256-byte ceiling HARNESS_TITLE_MAX_BYTES already holds a task title to.

HARNESS_TIMEOUT_MAX_MS

HARNESS_TIMEOUT_MIN_MS

HARNESS_TITLE_MAX_BYTES