glas-harness answered both open questions from ACTIVITY-WP-0032, so T01 is
resolved as option A: the ops_run pull queue stays and carries the versioned
harness_profile_ref plus attribution refs. The claiming executor passes the
request into Glas, which resolves or refuses before sandbox creation. This
changes the execution contract without also changing scheduling topology.
Two answers shaped the plan:
- harness_profile_ref and approach_hint coexist with distinct semantics.
approach_hint must never override, synthesize, or fall back from an absent or
invalid profile ref on governed execution — T02 must enforce that in code.
- The glas-harness catalog is authoritative and must not be mirrored. Glas has
no network validation service today, so emit-time remote validation is not
available.
T03 is corrected accordingly: validate locally and structurally, rely on the
execution-side Glas resolver as the mandatory fail-closed check, and record the
residual gap rather than papering over it with a mirrored catalogue.
Hub decision 147beec6-7fe7-4837-8e3a-4264a240379d.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tegwick
1c4b3c592c