# glas-harness

`glas-harness` is the primary execution-layer abstraction for governed agent
work. Consumers select a versioned Glas profile; Glas resolves the concrete
rein, model route, sandbox profile, tool policy, and limits, runs the outer
lifecycle, and returns one normalized evidence envelope.

The consumer contract does not name a Python rein class or provider CLI:

```text
assignment / channel / activity
  -> ExecutionRequest(harness_profile_ref=...)
  -> Glas profile resolution
  -> rein + model + sandbox + tool policy
  -> normalized ExecutionEvidence
```

## Profiles

List and validate every committed catalog profile, including its independently
declared runtime readiness:

```bash
glas-harness profiles
glas-harness profiles --json
```

Current constellations include:

- `harness.agent-dev-local@1.0.0`: `rein-aharness`, Claude Code model route,
  local bwrap sandbox.
- `harness.agent-dev-openweights-local@1.0.0`: `rein-openweights`, OpenRouter
  open-weight route, local bwrap sandbox.
- `harness.agent-dev@1.0.0`: `rein-aharness`, remote agent-dev sandbox.

The two local profiles are currently `blocked` by the missing sand-boxer
owner-execution/runtime path. The remote profile is `unverified`: it may be
used only as an explicitly labeled proof attempt. No committed profile is
currently declared `ready`.

Start a bounded proof attempt through the currently unverified remote profile:

```bash
glas-harness run \
  --harness-profile harness.agent-dev@1.0.0 \
  --repo /absolute/path/to/repo \
  --title "Bounded change" \
  --description "Make the requested change and commit it"
```

There is no governed default rein, model, sandbox, or tool profile. Unknown,
disabled, incompatible, ambiguous, and operationally blocked selections are
refused before sandbox creation. An unverified selection is allowed so a
bounded proof can establish or disprove readiness, and its evidence retains
that state.

After creation, execution uses only the reachability-derived sandbox workspace:
same-host commands use sand-boxer owner-mediated execution, while remote workspaces are
reached over SSH. The source checkout is provisioning input, not a rein workdir.

See [SCOPE.md](SCOPE.md), [INTENT.md](INTENT.md),
[docs/execution-profiles.md](docs/execution-profiles.md), and
[docs/harness-contract.md](docs/harness-contract.md).

## Development

```bash
uv run pytest -q
```