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

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
GLAS-WP-0004	workplan	Versioned execution-constellation profiles and explicit rein routing	infotech	glas-harness	finished	codex	execution-constellation-profiles	2026-08-20	2026-08-21	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:

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

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

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

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

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

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

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

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

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.