---
id: REIN-A-0004
type: workplan
title: "Profile-driven ops-run execution through Glas"
domain: infotech
repo: rein-aharness
status: blocked
owner: codex
topic_slug: rein-aharness
priority: high
created: "2026-08-22"
updated: "2026-08-22"
related:
  - ACTIVITY-WP-0032
  - ACT-ADR-006
state_hub_workstream_id: "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

```task
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

```task
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

```task
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

```task
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.