pub struct SessionContextV1 {Show 15 fields
pub grant_id: SessionGrantId,
pub grant_revision: HarnessRevision,
pub actor_run: CallerRunV1,
pub task: Option<RedactedTaskV1>,
pub sibling_runs: Vec<RedactedRunV1>,
pub read_permissions: HarnessReadPermissionsV1,
pub monitoring_visibility: HarnessMonitoringVisibilityV1,
pub child_task_count: u64,
pub child_task_subtree_depth: u64,
pub task_create: bool,
pub task_mutate: bool,
pub allowed_tool_ids: Vec<String>,
pub history_message_count: Option<u64>,
pub completed_turn_count: Option<u64>,
pub total_tokens: Option<u64>,
}Fields§
§grant_id: SessionGrantId§grant_revision: HarnessRevision§actor_run: CallerRunV1§task: Option<RedactedTaskV1>The calling run’s own task, redacted the same way as TaskGet –
present only when the grant’s task scope makes it visible (mirrors
actor_run.task_id).
sibling_runs: Vec<RedactedRunV1>Every OTHER run recorded against task (“what previous sessions did
on it”), redacted the same way as RunGet. Gated solely by task
being visible – independent of the grant’s runs read scope, which
governs the general run-browsing tools instead. Always empty when
task is None; never includes runs of another task.
read_permissions: HarnessReadPermissionsV1§monitoring_visibility: HarnessMonitoringVisibilityV1§child_task_count: u64Observation, not a budget: the number of tasks parented directly
under the calling run’s own task right now
(HarnessEngine::task_child_count), 0 if it has no children.
Unconditional – computed from actor_run’s own task the same way
the retired maximum_child_count wire field it replaces was
(independent of whether task above is redacted to None). That
retired field stated a cap that was validated for range but compared
against no actual child count anywhere in the service – a session
could read a limit here and still create children past it. The
owner’s ruling: do not cap a session’s children, detect them. Nothing
in this wire enforces an upper bound on this count.
child_task_subtree_depth: u64Observation, not a budget: the depth of the deepest chain of tasks
parented (transitively) under the calling run’s own task right now
(HarnessEngine::task_subtree_depth) – 0 if it has no children,
1 if it has children but no grandchildren, and so on. Unconditional
in the same sense as child_task_count above. Replaces the retired
maximum_child_depth wire field for the same reason child_task_ count replaces maximum_child_count (see that field’s doc comment).
Nothing in this wire enforces an upper bound on this depth.
task_create: boolD5, Slice D: mirrors grant.task_permissions.create – gates
g4a_task_create in allowed_tool_ids.
task_mutate: boolD5, Slice D: mirrors grant.task_permissions.mutate – gates
g4a_task_move in allowed_tool_ids.
allowed_tool_ids: Vec<String>§history_message_count: Option<u64>§completed_turn_count: Option<u64>§total_tokens: Option<u64>