glas-harness/workplans/GLAS-WP-0004-versioned-execution-constellation-profiles.md

---
id: GLAS-WP-0004
type: workplan
title: "Versioned execution-constellation profiles and explicit rein routing"
domain: infotech
repo: glas-harness
status: finished
owner: codex
topic_slug: execution-constellation-profiles
created: "2026-08-20"
updated: "2026-08-21"
state_hub_workstream_id: "0a7a6e20-2b52-562f-b052-ec7279fba31a"
---

# Versioned execution-constellation profiles and explicit rein routing

## Context

The accepted family architecture is sound: `glas-harness` owns the harness
contract and outer lifecycle while a concrete rein owns its inner agentic loop.
Both `rein-aharness` and `rein-openweights` implement the contract and have been
live-proven through the gateway.

The prototype does not yet make that flexibility real for normal consumers:

- `profiles/*.yaml` name a rein, sandbox profile, and tool profile, but no
  production code loads or validates those files;
- `glas-harness run` accepts `--sandbox-profile`, not a Glas harness profile;
- `run_task_through_rein()` silently constructs `ReinAharness` when no rein is
  injected;
- both committed profiles select `rein-aharness`, so the profile catalog does
  not demonstrate a second execution constellation;
- model selection is a rein-constructor detail (`ReinOpenWeights(model=...)`),
  not a versioned, attributable profile input; and
- `SandboxHandle`, `ToolCall`, `ToolResult`, and gateway result/evidence shapes
  are implemented but not versioned or declared compatible.

This workplan turns Glas from a proven adapter seam into the primary,
versioned execution-layer interface for agent workforce assignments and other
consumers. A consumer should be able to select or request an approved Glas
profile without embedding a concrete rein, vendor harness, base model,
sandbox, or tool-policy implementation into its own domain contract.

## Goal

Provide a versioned Glas execution request and profile path that resolves an
approved execution constellation:

```text
consumer execution request
  -> glas-harness profile/requirements resolution
  -> concrete rein + model route + sandbox profile + tool profile
  -> versioned Rein contract
  -> normalized execution result and audit evidence
```

The decisive proof is one semantically identical safe task executed through
two explicit Glas profiles—one backed by `rein-aharness`, one by
`rein-openweights`—without changing the workforce, role, goal, or task model.

## Boundaries and invariants

- `glas-harness` owns execution-profile schema, validation, resolution, rein
  registry lookup, sandbox coordination, actor attribution, and gateway
  evidence.
- A rein owns its inner agentic loop, backend-specific setup, and credentials,
  consistent with ADR-002.
- `llm-connect` and provider adapters retain inference/provider boundaries.
  Glas may carry a model route/reference and auditable resolved model, but it
  does not become an LLM API, model catalog of record, or secret broker.
- `sand-boxer` owns sandbox provisioning, profiles, placement, and teardown
  implementation; Glas selects and consumes a sandbox profile.
- Scheduling and blueprint sourcing remain outside the Glas gateway under
  ADR-003. `activity-core`, channels, or rein-local intake supply work; this
  workplan standardizes execution after invocation.
- Profiles and evidence contain credential-route references only, never secret
  values.
- Unknown, disabled, incompatible, or ambiguous profiles fail closed. No
  production invocation silently falls back to `rein-aharness` or a default
  model.
- Existing live `rein-aharness` operation remains available throughout the
  migration; cutover requires explicit compatibility and rollback evidence.

## Task: Version and freeze the minimum execution contract

```task
id: GLAS-WP-0004-T01
status: done
priority: high
state_hub_task_id: "2e340e91-7290-50aa-a79f-36440f833a2d"
```

Define a small versioned contract for the existing `Rein` lifecycle and its
boundary types. Use typed models for at least:

- execution request and resolved execution context;
- harness profile reference and profile revision/version;
- `SandboxHandle`, `ToolCall`, `ToolResult`, and execution summary;
- optional per-tool events and rein-specific extension metadata; and
- compatibility declaration between a profile, Glas contract version, and rein.

Document which fields are stable, optional, extensible, and sensitive. Preserve
the existing three-step lifecycle unless an implementation blocker is proven;
do not introduce speculative middleware or move rein internals into Glas.

**Done when:** the contract has an explicit version, validation tests cover
required/optional/unknown fields and incompatible versions, and both existing
rein adapters satisfy the same typed interface without fabricated evidence.

## Task: Implement the harness-profile schema, loader, and validator

```task
id: GLAS-WP-0004-T02
status: done
priority: high
state_hub_task_id: "a38be620-22dd-5d4c-802d-034c5bbf4ad0"
```

Turn `profiles/*.yaml` into a real runtime contract. The minimum profile should
identify:

- stable profile ID and semantic version;
- compatible Glas contract version;
- rein registry reference and required rein capabilities;
- sandbox profile reference;
- tool-policy/profile reference;
- model route/reference or bounded selection policy, including the resolved
  model identifier required in evidence;
- execution limits or references needed at the gateway boundary; and
- credential/policy route references, never values.

Implement deterministic discovery, parsing, validation, and lookup. Validate
the selected profile against `registry/reins/*.yaml`, including status and
capabilities. Reject duplicate IDs/versions, unknown reins, incompatible
contract versions, unavailable required capabilities, and unsafe inline secret
material.

**Done when:** committed profiles are loaded by production code, malformed and
incompatible fixtures fail closed with actionable errors, and the profile
catalog has schema and parity tests.

## Task: Make gateway and channel invocation explicitly profile-driven

```task
id: GLAS-WP-0004-T03
status: done
priority: high
state_hub_task_id: "88eb976b-a860-5fef-a077-0bff5bc2f6c4"
```

Add `--harness-profile <id[@version]>` to the CLI/channel contract and resolve
the rein, model route, sandbox profile, and tool profile through the loader.
Remove the implicit `ReinAharness()` choice from governed/production paths.

Keep direct rein injection as a narrow test/library seam if useful. If
`--sandbox-profile` must remain temporarily, classify it as an explicit legacy
or development path, warn clearly, give it a documented removal condition,
and never let it masquerade as profile resolution.

**Done when:** normal CLI and gateway execution requires an explicit valid
Glas profile, unknown/disabled/ambiguous selections perform no sandbox or rein
side effect, and tests prove that the resolved rein—not a hard-coded default—
receives the session.

## Task: Add two real execution constellations

```task
id: GLAS-WP-0004-T04
status: done
priority: high
state_hub_task_id: "329dcfae-a64f-5519-82c6-74d032a05192"
```

Normalize the existing `rein-aharness` profiles and add at least one committed
`rein-openweights` profile. Make the model and sandbox choices explicit enough
that audit evidence can reconstruct the selected constellation while keeping
provider credentials rein-local.

Cover both an exact pinned profile reference and the minimum safe form of a
requirements request if implemented. Requirements resolution must be
deterministic, explain why a profile matched, and refuse an ambiguous result;
it must not silently optimize for an undocumented model or cost preference.

**Done when:** the same safe task fixture can be routed to either rein by
changing only the Glas execution selection, and tests prove that the selected
model route, sandbox profile, and tool profile reach the correct adapter.

## Task: Normalize execution evidence and failure semantics

```task
id: GLAS-WP-0004-T05
status: done
priority: high
state_hub_task_id: "c5e74cb2-5e36-5b92-b295-2772c91b2d5c"
```

Define one result/audit envelope across reins containing at least:

- request/correlation ID, actor, project/target, and timestamps;
- Glas contract and profile ID/version;
- resolved rein ID/version, model route/resolved model, sandbox profile and
  sandbox ID, and tool profile;
- outcome, refusal/failure class, duration, token/cost fields when known, and
  commit/artifact references; and
- optional tool events with explicit availability/completeness semantics.

Keep unknown distinct from zero and unsupported distinct from empty. Redact
raw prompts, raw model output, secrets, and credential material from the State
Hub event. Ensure sandbox teardown and a compact failure event occur for
resolution, startup, execution, verification, and teardown failures.

**Done when:** both reins return the common envelope, negative-path tests cover
each lifecycle stage, and evidence identifies the complete execution
constellation without exposing sensitive content.

## Task: Publish the consumer contract and cross-repository handoffs

```task
id: GLAS-WP-0004-T06
status: done
priority: medium
state_hub_task_id: "81e9fd08-9ba9-5f7e-b8d4-a216d90723a1"
```

Document how consumer-owned agent instances, future agentic-resources
`RoleAssignment` records, activity-core work, and channels reference Glas.
Provide a fixture containing at least:

- `harness_profile_ref` or a versioned execution-requirements object;
- correlation, assignment, role, duty, goal, and resource-envelope references;
- expected output/evidence and execution limits; and
- explicit refusal behavior when the profile or envelope is unavailable.

Record cross-repository follow-ups as messages, capability requests, or live
work records in their owning repositories rather than implementing scheduling,
workforce allocation, or blueprint compilation inside Glas.

**Done when:** a consumer can construct a valid execution request without
knowing a rein class or provider CLI, and ownership documentation agrees across
Glas, agentic-resources, KaizenAgentic, activity-core, and the example reins.

## Task: Compatibility migration and dual-rein live proof

```task
id: GLAS-WP-0004-T07
status: done
priority: high
state_hub_task_id: "9c9657a9-77ba-58c7-9108-42f01a08feac"
```

Provide a staged migration for existing direct `rein-aharness` and
`--sandbox-profile` consumers:

1. inventory callers and preserve the current live path;
2. add explicit profiles matching current behavior;
3. run compatibility tests and one non-destructive live proof through each
   rein using approved credential routes;
4. compare normalized evidence and verify sandbox cleanup;
5. migrate callers individually with rollback instructions; and
6. remove the implicit rein default only after telemetry or repository search
   proves no governed caller depends on it.

No live provider credential may be printed, committed, or copied into State
Hub. Use credential routing before requesting access.

**2026-08-20 evidence:** the same bounded fixture was dispatched through both
explicit profiles. `rein-aharness` succeeded with a real commit and complete
tool-event evidence. `rein-openweights` resolved, ran, returned normalized
evidence, and tore down its sandbox, but the existing rein-local OpenRouter
lane was rejected by the provider with HTTP 401 before a model turn. Live
open-weight success waits on the owner repairing/rotating catalog route
`rein-openweights-openrouter-approle`; no sibling workload credential will be
borrowed. See `docs/evidence/GLAS-WP-0004-live-proof-2026-08-20.md`.

**Completed 2026-08-21:** after the operator repaired the key, the profile
completed the same fixture in three turns with 3,497 tokens and commit
`b0600b25066731c6e1fc458409429f76a844f959`; sandbox `220482bc` was verified
destroyed. The check also corrected the rein's documented-but-missing default
AppRole directory. Both real backend success criteria and rollback evidence are
now met.

**Done when:** both real backends complete the same bounded acceptance task
through explicit Glas profiles, current `rein-aharness` service behavior has
not regressed, rollback is documented, and the implicit production default is
retired or has a metered retirement record with a named owner.

## Task: Refresh architecture, operations, and release evidence

```task
id: GLAS-WP-0004-T08
status: done
priority: medium
state_hub_task_id: "cc3b59cf-5f66-5641-8d98-7feedbd51c10"
```

Update `INTENT.md`, `SCOPE.md`, the harness/channel contracts, registry docs,
CLI help, and operational examples to describe the implemented profile-driven
path. Correct stale current-state claims, including gateway State Hub reporting
that is already implemented. Add CI coverage for profile/catalog validation
and record the compatibility/versioning policy.

Run the full Glas suite plus the contract tests in both rein repositories.
Record non-secret live evidence and State Hub progress. Before marking the
workplan finished, hand off every remaining actionable item as a live work
record rather than leaving it only in prose.

**Done when:** documentation matches runtime behavior, tests and live proofs
pass, generated work records are synchronized, and the workplan has no
untracked residual implementation gap.

## Overall acceptance

This workplan is complete only when:

1. Glas profiles are runtime inputs, not unused YAML documentation.
2. Governed execution never silently defaults to `rein-aharness` or a model.
3. A consumer references Glas rather than importing or naming a concrete rein.
4. Two explicit profiles run the same safe task through different rein/model
   constellations with a common evidence envelope.
5. Profile, rein, model, sandbox, tool policy, actor, and contract versions are
   reconstructable from non-secret evidence.
6. Scheduling, blueprint ownership, provider credentials, sandbox provisioning,
   and workforce allocation remain with their declared owners.
7. Existing live `rein-aharness` operation has a tested compatibility and
   rollback path.