# 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 executable profile:

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

Run a task through an explicit profile:

```bash
glas-harness run \
  --harness-profile harness.agent-dev-local@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, and ambiguous selections are refused before sandbox
creation.

After creation, execution uses only the reachability-derived sandbox workspace:
same-host namespaces are entered with `nsenter`, 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
```