rein-aharness/workplans/REIN-A-0004-glas-profiled-ops-runs.md

id	type	title	domain	repo	status	owner	topic_slug	priority	created	updated	related	state_hub_workstream_id
REIN-A-0004	workplan	Profile-driven ops-run execution through Glas	infotech	rein-aharness	blocked	codex	rein-aharness	high	2026-08-22	2026-08-22	ACTIVITY-WP-0032 ACT-ADR-006	443bf39c-11e1-5db8-9d91-7b852aeefdb6

REIN-A-0004 — Profile-driven ops-run execution through Glas

Origin

Activity Core handoff 4ed3422a-b42c-4408-843c-f63c3e86cf3e reports that the claim consumer currently drops harness_profile_ref and execution_refs. A profiled row would consequently enter the legacy select_approach path and could execute a different constellation than the producer authorized.

The related handoff 69710949-9726-4fd0-aef3-1c7075870410 reports that llm-connect provider errors lose their safe structured status at this boundary, making a provider 401 look like an undifferentiated 502 transport failure.

Carry the profile selector and attribution references

id: REIN-A-0004-T01
status: done
priority: high
state_hub_task_id: "32501497-16b7-567f-9925-215e1784bc2a"

Extend OpsRun.from_api with harness_profile_ref and the allowlisted execution_refs. Preserve the queued selector verbatim for the authoritative Glas resolver; do not translate it into an approach hint.

Done 2026-08-22: both fields are normalized onto OpsRun and covered by the API projection test.

Route profiled rows through the Glas gateway

id: REIN-A-0004-T02
status: done
priority: high
state_hub_task_id: "ead932ef-f8c9-5cd5-8268-c96048f82718"

For a row with a profile, resolve its target checkout, build the Glas ExecutionRequest, and invoke run_execution before any sandbox is created by this consumer. Complete or fail the ops run with the full GatewayResult. Profile refusal and gateway failure are terminal and never fall back to select_approach. Profile-absent rows retain the legacy coexistence path.

Done 2026-08-22: glas_execution.py resolves the queued checkout, maps the complete contract 1.0 request (including attribution refs), and invokes Glas through lazy runtime imports. The claim loop branches on profile presence before legacy selection and sends the full GatewayResult to Activity Core. Its own returned detail retains only ExecutionEvidence. Tests prove success, terminal refusal, no legacy fallback, and profile-aware queue inspection. A real sibling-package probe of harness.unknown@9.9.9 returned refused/resolution with no sandbox id.

Preserve safe llm-connect provider failure context

id: REIN-A-0004-T03
status: done
priority: medium
state_hub_task_id: "b0af0efc-689e-586f-a0e2-78df411c7834"

On an HTTP error, retain only llm-connect's allowlisted error, provider_status, provider, and model fields plus a bounded message. Never copy the raw provider response or credential material into an ops-run result.

Done 2026-08-22: HTTP errors retain exactly the four safe diagnostic fields plus a 400-character message. Tests cover the upstream 401 hidden behind 502, redaction-by-allowlist, bounding, and unusable bodies.

Deploy and coordinate one production proof

id: REIN-A-0004-T04
status: wait
priority: high
state_hub_task_id: "b19a4dab-d6d7-537a-8c8f-77217f0d9069"

Install the Glas and sand-boxer sibling packages into the railiance01 claim worker environment, deploy the source-tested consumer, and coordinate one low-risk profiled definition with Activity Core. Evidence must show the queued profile, resolved rein/model/sandbox/outcome, and teardown/commit facts.

Progress 2026-08-22: source verification is green (96 tests, compilation, and diff checks). Packaging exposes the local Glas/sand-boxer extra and the deployment rsync now excludes .venv, preventing workstation-bound shebangs from overwriting the live worker environment. railiance01 is healthy on the legacy worker but still needs the Glas checkout/package install, deployment, restart, and coordinated pilot.

Deployment then exposed a pre-existing upstream database mismatch: the live Activity Core image selects ops_runs.harness_profile_ref, but production PostgreSQL has not applied migration 0008, so every claim returns 500. The worker's prior error path retried that failure every two seconds; it now uses the configured 30-second backoff for claim errors and reserves the short pause for cycles that actually claimed work. Activity Core must apply/verify its migration before the coordinated pilot can run.

Live deployment evidence: railiance01 runs consumer db58801, glas-harness ae2a706, and sand-boxer 20258de; the user service is active, the packaged profile catalog validates all three profiles, and the remote unknown-profile probe refused before sandbox creation. Journal timestamps 21:59:13, 21:59:43, and 22:00:13 UTC prove the corrected 30-second error backoff. Activity Core handoff 413a4041-cfb3-4d02-a41a-1d92b3de06af contains the production traceback and requests migration application before a pilot is scheduled. T04 waits only on that upstream repair and the coordinated low-risk proof.