docs: plan explicit execution cleanup and reporting outcomes

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0726e-5232-73f2-aaca-2c05ceb62efb
This commit is contained in:
tegwick 2026-09-06 11:10:04 +02:00
parent f8942c42e8
commit 76a68efb21

View file

@ -0,0 +1,58 @@
---
id: GLAS-WP-0013
type: workplan
title: "Expose cleanup and reporting outcomes to execution consumers"
domain: infotech
repo: glas-harness
status: active
owner: codex
topic_slug: execution-outcome-evidence
created: "2026-09-06"
updated: "2026-09-06"
---
# Execution outcome evidence
## Priority and boundary
The first real local profile remains the highest priority in GLAS-WP-0012,
with owner activation/runtime work already registered. This plan closes the
independent observability gaps identified in the September scope assessment.
A failed execution can currently mask cleanup/destruction failures, while the
caller cannot distinguish accepted, failed or disabled Hub reporting.
Use additive, defaulted outcome fields on existing result models. Preserve the
original execution failure and report secondary teardown outcomes separately.
Expose reporting acceptance to the direct caller without recursive reporting,
raw exception disclosure to Hub, automatic execution retries or a durable queue.
Memory, channels, subagents and aggregate budget enforcement remain design gaps,
not work authorized by this bounded plan. No profile readiness changes.
## Record cleanup and destruction independently
```task
id: GLAS-WP-0013-T01
status: progress
priority: high
```
Evidence reports cleanup and sandbox destruction as not attempted, succeeded
or failed. Preserve the original failure stage if execution already failed,
but always expose secondary failure outcomes. Destroy is attempted even if
cleanup raises. Successful execution becomes failed when teardown fails.
Test normal, pre-creation refusal, startup failure and combined failure paths.
## Return State Hub reporting outcome
```task
id: GLAS-WP-0013-T02
status: todo
priority: high
```
GatewayResult reports not requested, accepted or failed. Reporting is attempted
once after evidence is final; no-Hub makes no request. Hub failure must not
rerun the task or change its execution outcome. Test successful reporting,
HTTP refusal/unavailability, disabled reporting and failure evidence redaction.
Document that acceptance is an HTTP result, not durable audit delivery or an
exactly-once guarantee. Run full tests and catalog validation; update SCOPE.