coulomb/glas-harness
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Make profile runtime readiness explicit
Some checks failed
ci / validate (push) Has been cancelled
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0233b-178d-7162-b92f-31a31ea8ca9b
This commit is contained in:
tegwick 2026-08-23 11:32:23 +02:00
parent a224e71555
commit cac605abd7
19 changed files with 339 additions and 41 deletions
Download patch file Download diff file Expand all files Collapse all files

19
history/2026-08-23-scope-vs-intent-assessment.md
View file

@ -68,10 +68,10 @@ not a positive local execution path.
`GLAS-IN-0002` owns the sand-boxer contract for command execution, mounted or
imaged rein runtime, explicit model egress, credential delivery, and teardown
evidence. `GLAS-WP-0005-T05` remains waiting on it.
2. **Profile readiness semantics — high.** A catalog-valid `enabled` profile is
currently presented alongside profiles that cannot dispatch on the deployed
runtime. `GLAS-IN-0005` requires an explicit readiness/enablement contract,
including whether unproven profiles must be disabled or separately labeled.
2. **Profile readiness semantics — resolved 2026-08-23.** `GLAS-WP-0008`
separated catalog enablement from typed `ready`, `unverified`, and `blocked`
runtime states. Known blockers now refuse before sandbox creation, while a
labeled unverified profile remains available for a bounded proof attempt.
### Record-governance gaps
@ -92,13 +92,14 @@ or claim them as capabilities.
## Recommended sequence
1. Complete `GLAS-IN-0002` and capture one positive, source-isolated rein run.
2. Resolve `GLAS-IN-0005` so catalog output distinguishes selectable schema
from deployable runtime capability.
2. Use the implemented readiness state in catalog output and evidence; promote
a profile to `ready` only with a positive evidence reference.
3. Reassess whether the remote profile is an operational recovery path or an
unproven declaration; retain it only with evidence and owned runtime setup.
4. Add broader harness pillars only when a real channel/consumer supplies the
boundary and evidence requirements.
Until steps 1–2 complete, describe Glas as a secure, fail-closed execution
router nucleus—not yet the default or unified agent harness service promised by
the maturity target in `INTENT.md`.
Until step 1 completes and at least one profile has positive runtime evidence,
describe Glas as a secure, fail-closed execution router nucleus—not yet the
default or unified agent harness service promised by the maturity target in
`INTENT.md`.