glas-harness/docs/intakes/residuals.md

# glas-harness residual intakes

## GLAS-IN-0001 — Restore open-weight live-profile credential lane

```yaml
id: GLAS-IN-0001
kind: intake
title: "Restore the rein-openweights OpenRouter lane and close the dual-profile live proof"
lane: blue
status: done
priority: high
owner: ops-mason
repo: glas-harness
origin: residual
origin_ref: GLAS-WP-0004
description: |
  On 2026-08-20, harness.agent-dev-openweights-local@1.0.0 resolved and
  dispatched the same bounded fixture used by the successful rein-aharness
  profile. The existing rein-local credential reached OpenRouter but the
  provider returned HTTP 401 User not found before a model turn. Glas returned
  normalized, redacted failure evidence and tore down sandbox bc9dec6a.

  Route catalog id: rein-openweights-openrouter-approle. Credential values must
  not be placed in this record, State Hub, Git, or chat.

  The owning credential operator should rotate or repair that exact workload
  lane, verify field presence without disclosure, and notify glas-harness.
  Then rerun the bounded acceptance task through
  harness.agent-dev-openweights-local@1.0.0, record a real commit plus cleanup
  evidence, and mark GLAS-WP-0004-T07 done. Do not borrow llm-connect's
  separate OpenRouter credential.

  Completed 2026-08-21. The repaired lane authenticated after removing a stale
  inherited OPENROUTER_API_KEY override and selecting the standard AppRole
  directory. The profile completed in 3 turns, spent 3,497 tokens, produced
  commit b0600b25066731c6e1fc458409429f76a844f959, and sandbox 220482bc was
  verified destroyed. The AppRole directory is now the code default.
state_hub_intake_id: "01a02b76-e138-788c-9809-1e970c752d5d"
```

## GLAS-IN-0002 — Provide executable sandbox runtime reachability

```yaml
id: GLAS-IN-0002
kind: intake
title: "Make bwrap reachability executable for governed Glas reins"
lane: red
status: todo
priority: high
owner: sand-boxer
repo: glas-harness
origin: residual
origin_ref: GLAS-WP-0005
description: |
  GLAS-WP-0005 corrected the gateway so a rein command must execute through
  the sand-boxer reachability descriptor and can no longer operate on the
  caller's source checkout. The existing profile.bwrap-local environment does
  not yet carry an executable rein runtime: ext.bwrap mounts /usr, /bin, /lib,
  /lib64, and resolv.conf, while rein-aharness/rein-openweights and their
  dependencies live outside those mounts. The open-weight profile also needs a
  governed egress/credential-delivery answer rather than the current empty
  network allow-list.

  A 2026-08-21 managed-agent probe also found direct consumer nsenter denied on
  the reported pid (IPC/UTS setns operation not permitted). Determine whether
  sand-boxer should expose an owner-implemented exec operation instead of
  requiring each consumer to call nsenter, and provide the runtime mount/image,
  identity, and network contract needed by both local profiles. Do not restore
  host-side execution as a workaround.

  A production retry on 2026-08-23 removed the upstream actor mismatch and
  reached the same boundary with governed actor agt. Glas created sandbox
  d750cd5c, then failed closed at session_start before dispatch or commit
  because direct nsenter remained Operation not permitted. The sandbox was
  destroyed and its workspace removed. Loading Ubuntu's bwrap user-namespace
  AppArmor profile kept bwrap alive with child CapEff=0 but did not grant the
  consumer namespace-entry authority. This strengthens the owner-exec need; it
  does not justify widening host execution.

  2026-09-05 handoff refresh: sand-boxer b6655d8 now supplies owner-mediated
  execution and bounded stdin. Glas replaced direct nsenter and host task-file
  writes with that operation, preserving exact actor/project/request run_id,
  profile credential_route_refs, and timeout. The non-secret gateway proof
  passed in sandbox e3907e55: source absent and mutation refused, sandbox-only
  commit, loopback-only network, mode-0600 task removed before teardown, and
  destroyed workspace. Evidence: docs/evidence/GLAS-WP-0005-owner-boundary-2026-09-05.md.

  Remaining owner work: supply the declared rein runtimes and dependencies,
  governed credential delivery and explicit required egress, then prove a real
  rein command through the Glas adapter before changing either local profile
  from blocked. Glas owns the final profile review and acceptance run once the
  sand-boxer runtime contract is available. The deterministic non-secret proof
  does not satisfy this production acceptance. GLAS-WP-0005 can close its
  boundary-hardening scope with this registered live residual still open.

  GLAS-WP-0012 now tracks the first (Claude) local-profile acceptance, starting
  from harness.agent-dev-local@1.0.0. Its owner return contract and baseline
  are in docs/local-profile-acceptance.md. The corresponding owner dependency
  is SAND-WP-0014-T05; its current OpenRouter credential requirement does not
  establish the Claude route. Keep this intake open for the open-weight
  profile even after the first Claude profile is proven.

  2026-09-05 owner implementation: SAND-WP-0015 now provides digest-pinned
  standalone Python runtime mounts and private HOME/XDG/TMP state. Real rein
  CLI startup proof d4de9531 passed with read-only runtime, absent source,
  clean worktree, cross-exec private-state persistence and workspace removal;
  owner API smoke and 132 tests pass. No production profile selects the
  temporary artifact, and no model call occurred. Claude workload auth mode/
  concrete lane, credential delivery, enforced egress, pinned Claude runtime,
  and deployment/Glas acceptance remain open in SAND-WP-0015-T04.

  Done when a non-secret probe and one real rein command execute inside the
  namespace, the source checkout is not visible/mutable, required egress is
  explicit, and teardown removes the sandbox workspace.
state_hub_intake_id: "01a02b76-f020-7d60-a3ce-12a34c13ebce"
```

## GLAS-IN-0003 — Grandfather the legacy bootstrap identifier scheme

```yaml
id: GLAS-IN-0003
kind: intake
title: "Grandfather the legacy GLAS-0001 bootstrap identifiers"
lane: green
status: todo
priority: medium
owner: repo-manager
repo: glas-harness
origin: residual
origin_ref: GLAS-0001
description: |
  The finished bootstrap workplan predates the fleet kind registry and uses
  GLAS-0001 plus GLAS-0001-T01 through T03. Those records already have stable
  State Hub UUIDs and must not be renamed. Repo Manager's primary registrar
  reports them as C-35 contradictory identities, while State Hub also reports
  the three task ids as C-31 unregistered species.

  Coordinate with the canon steward to grandfather this exact historical
  scheme, matching the treatment for other pre-canon bootstrap identifiers.
  Keep the existing file ids and UUID bindings unchanged. Done when Repo
  Manager identity preflight and statehub fix-consistency accept the four
  legacy identifiers without C-35 or C-31 warnings.
state_hub_intake_id: "01a02b78-adff-70b5-8088-594784edff23"
```

## GLAS-IN-0004 — Align the mandated ad hoc convention with identifier canon

```yaml
id: GLAS-IN-0004
kind: intake
title: "Make ADHOC workplans valid under the fleet identifier canon"
lane: green
status: todo
priority: medium
owner: repo-manager
repo: glas-harness
origin: residual
origin_ref: GLAS-WP-0006
description: |
  The repository's generated agent instructions mandate
  workplans/ADHOC-YYYY-MM-DD.md with ADHOC-YYYY-MM-DD-Txx task ids for small,
  low-risk fixes. On 2026-08-23, statehub fix-consistency accepted the task id
  but Repo Manager identity preflight raised C-35 because the matching
  ADHOC-2026-08-23 workplan id is absent from the canon kind registry.

  Align the generated convention, Repo Manager identity preflight, and State
  Hub synchronization. Either register the documented ad hoc workplan form or
  replace the generated instruction with one canonical representation. Prove
  the chosen form through registrar-reconcile without a contradictory identity
  warning. Do not grandfather the one discarded local attempt; no UUID was
  assigned and GLAS-WP-0006 is the authoritative record for that work.
state_hub_intake_id: "01a02bde-7d1e-7af3-9eba-aecc8f50365c"
```

## GLAS-IN-0005 — Make profile operational readiness explicit

```yaml
id: GLAS-IN-0005
kind: intake
title: "Separate profile selection enablement from runtime readiness"
lane: red
status: done
priority: high
owner: glas-harness
repo: glas-harness
origin: residual
origin_ref: GLAS-WP-0007
description: |
  The catalog currently labels all three committed profiles enabled when their
  schemas and rein capabilities are selectable. That status does not prove the
  selected host can execute the rein inside its sandbox transport. Both local
  profiles currently fail closed at session_start on the sand-boxer owner-exec
  boundary, while the remote profile lacks a positive post-hardening proof.

  Define and implement an explicit operational-readiness contract. Decide
  whether unavailable profiles must be disabled, carry a separate readiness
  state, or be filtered through a bounded preflight. Catalog and CLI output
  must not imply runtime executability from schema validation alone. Coordinate
  with GLAS-IN-0002 for local owner-exec/runtime evidence; do not add a host
  fallback or claim readiness from lifecycle-only proof.
state_hub_intake_id: "01a02dce-b761-75e6-861a-8abf8b8e0072"
```

Completed by `GLAS-WP-0008` on 2026-08-23. Catalog enablement is now separate
from typed operational readiness. Both local profiles are `blocked` by
`GLAS-IN-0002` and refuse before sandbox creation; the remote profile is
`unverified` and may be used only for a labeled bounded proof attempt. Catalog
and execution evidence expose the state, and no host fallback was added.