rein-aharness/workplans/REINAH-WP-0003-governed-runtime-integrity.md

---
id: REINAH-WP-0003
type: workplan
title: "Governed runtime integrity and intent convergence"
domain: infotech
repo: rein-aharness
status: active
owner: codex
topic_slug: rein-aharness
priority: high
created: "2026-08-23"
updated: "2026-09-04"
related:
  - REIN-A-0004
  - GLAS-IN-0002
  - ACTIVITY-WP-0032
  - CUST-WP-0065
state_hub_workstream_id: "eba2eff1-10a7-50a3-a70b-14e7d398f27f"
---

# REINAH-WP-0003 — Governed runtime integrity and intent convergence

## Origin

The 2026-08-23 intent–scope assessment found that the deployed v0.1 worker is
a useful sequential Activity Core consumer, but its strongest production
claims exceed its current enforcement and evidence:

1. direct runs accept any `HEAD` change without a repository lock, clean-tree
   gate, changed-path validation, remote-state check, or lease-loss stop;
2. the strategic profile-driven route currently fails closed before dispatch
   on upstream executable sandbox/runtime/egress work in `GLAS-IN-0002`;
3. metrics and best-effort Hub reporting are not an atomic or reconciled part
   of run acceptance;
4. FI/Binky-specific approaches remain inside the shared runtime despite the
   `INTENT.md` prohibition on tenant logic;
5. the active production topology is a host user service while Kubernetes is
   a sleeper placeholder, and optional cross-package contracts can skip in the
   default development environment; and
6. credential and policy enforcement ownership is distributed across the
   execution chain although `INTENT.md` describes this repo as the only holder
   and enforcement point.

Custodian message `c02a26b9-421c-4373-880a-3a17dd89db65` also requests the
missing authoritative `.repo-classification.yaml`. That concrete governance
gap is included in the baseline task rather than left as an untracked side
request.

## Priority and sequencing

- **Critical:** T02–T03 make repository mutation and accepted evidence safe.
- **Critical external gate:** T06 proves the current profiled path only after
  `GLAS-IN-0002` supplies executable reachability/runtime/egress.
- **High:** T05 makes the deployed topology and contract test surface truthful
  before another tenant or worker is added.
- **High:** T04 removes tenant coupling so reuse does not multiply code paths.
- **Enabling:** T01 fixes classification and records the responsibility model
  that all implementation tasks must enforce.

T02, T04, and T05 may proceed in parallel after T01. T03 follows T02. T06 is
the final integration gate and must not manufacture a host-side fallback while
waiting on the sandbox owner.

## Establish the governance and enforcement baseline

```task
id: REINAH-WP-0003-T01
status: done
priority: high
state_hub_task_id: "596fc138-1ee3-5602-95c7-0bd728ec70ab"
```

Review the Custodian classification canon and create the authoritative
`.repo-classification.yaml`, preserving repo identity separately from sector
metadata. Validate it with the fleet tool, commit it, and report the revision
to the Custodian owner request.

In the same task, record an ADR or decision that distinguishes:

- the strategic Activity Core → Glas → rein → sandbox route;
- the transitional profile-absent and issue-core compatibility routes;
- ownership of queue identity, actor identity, tool policy, filesystem and
  network isolation, model routing, credential acquisition/injection/revocation,
  repository acceptance, and durable evidence; and
- which failures must be terminal, retryable, or reconciled.

Do not edit `INTENT.md` merely to match current shortcuts. Either demonstrate
how its “only credential holder / only policy enforcement point” language is
implemented by the governed chain, or amend it through the explicit decision
with sibling-owner acknowledgement.

**Done when:** classification validation passes and the Custodian has the
revision; the responsibility matrix has named owners and evidence at every
boundary; direct/legacy paths have an explicit retirement or support posture;
and T02–T06 can cite stable decisions rather than infer ownership from code.

### Progress — 2026-08-23

- Published the canon-valid owner classification at revision `81f9279`:
  `tooling`, primary sector `agents`, secondary `infotech`. Custodian report:
  message `e92be7f9-f51d-4a40-9eec-adf2132d5c2d`.
- Proposed `docs/adr/ADR-002-governed-execution-responsibility-chain.md` with
  explicit strategic/compatibility routes, responsibility/evidence matrix,
  and terminal/retry/reconciliation semantics. Pending decision:
  `4177b0b7-0b32-4f35-861b-28700531e58c`.
- Requested explicit owner review from Activity Core
  (`4b92da2c-9809-4bbe-be2e-4b1e53e13e13`), Glas
  (`4fe6a048-6ca8-4e52-bb22-e2a82725191c`), sand-boxer
  (`7fd35fd4-b0e1-42f0-bb56-a983a3e25c78`), and llm-connect
  (`c5d1dc62-3dca-4ac8-b3b5-d570d723ceda`). T01 remains `progress` and
  downstream tasks remain `wait` until those reviews are reconciled.
- Glas approved the proposed boundary without edits in message
  `006fa46f-9419-4f61-90ff-0c3b6bc294c1`. Activity Core, sand-boxer, and
  llm-connect acknowledgements remain pending.
- Activity Core review `428abb02-75dc-450d-a7f6-56fc715409ab` confirmed the
  strategic route and no-fallback posture but correctly rejected an overstated
  queue-identity guarantee. ADR-002 now distinguishes the current shared caller
  token from the required principal-to-`worker_id` binding, requires Activity
  Core itself to reject heartbeat/close mutations at or after lease expiry,
  and excludes operator/SSO identity except through an audited break-glass
  contract. Published revision `c230f33` (ADR SHA-256 `a821b29e…de90b`) and
  requested exact-revision acknowledgement from Activity Core
  (`4d1f08fa-9857-438e-8629-758bf5420446`), sand-boxer
  (`acc210a2-dd9f-4705-bb4a-9e3ac4b0d142`), llm-connect
  (`39f69388-0249-4b66-9633-f37b1a0b386a`), and Glas confirmation
  (`704aa396-52b7-4c9f-80b7-6cf8a81ce0a1`). Glas reconfirmed the exact
  revision and digest in `9638537b-e3c3-414d-a2d7-8beab61a4e1f`; revised
  Activity Core, sand-boxer, and llm-connect acknowledgements remain pending.
- Activity Core message `900801f4-0641-4e87-90e6-0279b6c892a6` reports the
  requested boundary deployed under `ACTIVITY-WP-0036` at revisions `f0a897e`
  and `3cd5250`: the worker token is bound to configured
  `rein-aharness@railiance01`, mismatched body and operator/SSO identities are
  rejected, and heartbeat/complete/fail enforce row-locked active leases with
  equal-to-expiry treated as expired. Its 468-test suite and live spoof refusal
  passed. ADR-002 now records this as deployed current state; natural
  heartbeat/late-close production evidence remains pending for the next real
  claimed row rather than a manufactured run. Published revision `36e1096`
  (ADR SHA-256 `84b47d2e…bb206f`) and requested final exact-revision
  acknowledgement from Activity Core (`532c4245-d3fe-408b-b21e-fd0300de5288`),
  sand-boxer (`1bf5768c-f77a-4f08-ae02-25caff9f0166`), llm-connect
  (`4bd35ce5-9c84-4695-83d5-c9bd16fa1b77`), and Glas
  (`52567711-1100-43c0-9f8e-40650738eb04`).
- 2026-08-29: this State Hub instance no longer serves those request
  message ids (GET 404). Glas approval of the earlier revision still
  stands in the ADR text; Activity Core, sand-boxer, and llm-connect
  exact-revision acknowledgements of `36e1096` /
  `84b47d2e…bb206f` remain the T01 gate. Reminder messages resent from
  `rein-aharness`: Activity Core `92b80a06-dc0e-46bd-a5c7-b43d1babe9ba`,
  Glas `afc2af7b-8246-482b-a6f5-7acfc2aa32b1`, sand-boxer
  `b220425d-5295-4bf3-af4c-34ec838f1175`, llm-connect
  `4cc4a2cc-584b-423d-8f34-a0bcd981f1c7`.
- 2026-08-29: operator Bernd Worsch accepted ADR-002 as written.
  `INTENT.md` and ADR-001 slogan wording were amended the same day.
  Sibling exact-revision acknowledgements remain welcome as recording,
  not a gate. T01 is `done`; T04 and T05 are unblocked.

## Make each repository run a lease-bound transaction

```task
id: REINAH-WP-0003-T02
status: done
priority: high
state_hub_task_id: "31da4226-27c0-5e3c-baeb-de01e07cebb1"
```

Implement one repository transaction guard shared by direct `TaskSpec` runs
and every legacy approach that mutates a checkout. It must:

- key a process-safe lock by canonical repository identity and store lock state
  outside the target checkout;
- capture branch/detached state, `HEAD`, working-tree/index state, relevant
  local remote-tracking refs, and the task/run correlation before mutation;
- refuse unattended production mutation on a dirty or ambiguous baseline,
  while preserving all pre-existing operator changes;
- retain the Activity Core lease for the transaction and make heartbeat/lease
  loss observable to the executor so work cannot silently finish under an
  expired owner; and
- release the repository lock on success, refusal, timeout, signal, adapter
  error, and result-close failure without deleting user data.

Keep production concurrency at one until this guard is proven. Do not add
distributed concurrency merely because a local lock exists.

**Done when:** tests cover concurrent claims for one checkout, distinct repos,
dirty baselines, detached or moved `HEAD`, heartbeat/lease loss, timeout,
signal cleanup, and close failure; a refused run changes neither repository nor
remote refs; and the result carries a bounded transaction identifier and
baseline evidence.

### Preparation — 2026-08-23

Added the production-inert core transaction primitive in
`rein_aharness/repository_transaction.py`. It keys a private external `flock`
by the resolved Git common directory, captures branch/detached `HEAD`, clean or
dirty index/worktree digests, upstream and remote-tracking refs, and exposes a
bounded transaction/baseline evidence envelope. Ten focused tests cover
cross-process same-repo contention, path aliases, distinct repos, dirty/staged/
untracked baselines, detached `HEAD`, private lock metadata, exception cleanup,
and non-repository refusal.

The primitive is intentionally not wired into `runner.py`, legacy approaches,
or the claim loop while ADR-002 still awaits Activity Core, sand-boxer, and
llm-connect acknowledgements. Controlled moved-`HEAD` acceptance is prepared
under T03 below; lease-loss cancellation, timeout/signal integration, and
result-close reconciliation remain outstanding; T02 is now `progress`.

### Lease observability slice — 2026-08-23

Added `rein_aharness/lease_monitor.py`, a thread-safe, adapter-neutral lease
state primitive. It records one bounded loss envelope, provides a waitable loss
event, and invokes an optional cancellation callback exactly once. The claim
loop heartbeat now feeds this monitor and emits only bounded error type/time
evidence instead of raw provider exception text. This establishes the signal
needed by execution and acceptance boundaries without pretending that adapters
can already cancel in-flight work. Remaining work is to classify Activity Core
responses, connect cancellation at each adapter boundary, and refuse result
acceptance/close after loss. The claim loop now implements that last refusal for
normal and successful profiled executions: a lost lease returns bounded loss
evidence and skips Activity Core completion/failure calls, leaving reconciliation
to the owner of the expired lease. Adapter exception paths now also stop before
close when lease loss raced the failure; otherwise they return only an exception
class marker rather than leaving an unbound result or retaining provider text.
`OpsRunError` now carries bounded action/status metadata, and heartbeats treat
explicit ownership-rejection statuses as lease loss while allowing transport
errors to retry without immediately abandoning a run.

### Adapter cancellation slice — 2026-08-29

Connected lease-loss, timeout, and signal cancellation at the adapter
boundaries and enabled the repository transaction after ADR-002 acceptance.

- `rein_aharness/execution_cancel.py` is a one-shot, adapter-neutral cancel
  token. It records a bounded reason (`lease-loss` / `timeout` / `signal`),
  invokes registered process/HTTP stoppers once, and is published to adapters
  through an explicit argument or `using_cancel()` context.
- The claim-loop heartbeat now cancels that token when Activity Core rejects
  ownership. SIGINT/SIGTERM also cancel the active run. In both cases the loop
  still skips Activity Core complete/fail and returns bounded cancellation or
  lease-loss evidence.
- `AgenticClaudeCodeAdapter` waits on `Popen` for both blocking and streaming
  sessions so an in-flight Claude process can be killed. `LLMConnectClient`
  closes its HTTP client. Glas checks the token before and after
  `run_execution` and refuses a late success; it still cannot abort an
  in-flight sandbox (sand-boxer residual).
- `run_task` records `execution cancelled (<reason>)` without session output.
  Tenant brief executors pick the token up through the active-cancel context
  when they call llm-connect.

The repository lock is now wired into `runner.py`, legacy mutating approaches,
and the profiled claim path following operator acceptance of ADR-002. Remaining
T02 work is to prove lock release on timeout, signal, and result-close failure
and close the task with the resulting bounded evidence.

### Review checkpoint — 2026-09-04

Reviewed the cancellation and transaction wiring together and corrected the
affected profiled-result and clean-baseline test setup. Full verification passes:
`209 passed, 1 skipped`. T02 remains `progress` until the named timeout, signal,
and result-close lock-release cases are covered directly.

### Completion — 2026-09-04

Added direct integration proof that the canonical repository lock is released
after an adapter timeout, Activity Core lease loss, process-signal cancellation,
and a terminal result-close transport failure. The close-failure test also
confirms transaction evidence survives in the bounded process result. Refusal
coverage now proves both the checkout status and local remote-tracking refs are
unchanged. Profiled tests use disposable repositories, and an autouse fixture
keeps runtime state outside operator-owned paths. The documented full-suite
command passes without an environment override: `212 passed, 1 skipped`.

Together with the existing cross-process contention, distinct-repository,
dirty/staged/untracked, detached/moved-HEAD, metadata, remote-ref, bounded
evidence, and lease-cancellation cases, all T02 exit criteria are met. T02 is
`done`; T03 is unblocked.

## Verify accepted commits and reconcile metrics/reporting

```task
id: REINAH-WP-0003-T03
status: wait
priority: high
state_hub_task_id: "6297dee4-c10f-5d5f-8d7c-7edfafa27e7f"
```

Replace the current `head_after != head_before` success test with explicit
repository acceptance under the T02 transaction. At minimum verify:

- the accepted workload commit descends exactly from the recorded baseline
  according to the declared one-commit or bounded-commit policy;
- changed paths conform to the task/profile grant and Git metadata, hooks, and
  remote configuration were not altered;
- the resulting index and working tree match the declared postcondition;
- no local remote-tracking ref moved unexpectedly and any path that is allowed
  to push has a separate explicit grant and evidence; and
- evidence identifies the accepted commit(s), changed paths, baseline, policy,
  and validation outcome without retaining prompts or provider output.

Decide and implement metrics atomicity: either include repo-owned kaizen
metrics in a declared harness-authored evidence commit or move them to an
external/durable channel with a defined projection back to the instance. A
successful run must not become dirty after commit verification. Add a bounded
outbox or reconciliation mechanism for required State Hub/Activity Core close
evidence; best-effort telemetry may remain non-blocking only when labelled as
such.

**Done when:** adversarial tests reject unrelated commits, extra paths, dirty
post-state, metadata/config edits, and ungranted remote movement; success
leaves the checkout in its declared state; metrics and required completion
evidence survive a temporary Hub/API outage without duplicating the workload
commit; and docs no longer claim checks that the code does not perform.

### Preparation — 2026-08-23

Extended the production-inert transaction core with an explicit
`RepositoryAcceptancePolicy` and read-only post-run validator. It now requires
same-branch descendant commits within declared bounds, repository-relative path
patterns, a clean index/worktree, unchanged local remote-tracking refs, and an
unchanged digest of protected Git config, hooks, and info metadata. Accepted
evidence contains bounded commit/path lists plus policy, path-set, baseline, and
post-state digests; it retains no prompt or provider output.

Sixteen additional adversarial cases bring the focused transaction suite to 26
tests. They cover a valid one-commit result, unrelated history, excess commits,
ungranted paths, glob boundary semantics, dirty post-state, branch movement,
unchanged `HEAD`, remote-ref movement, Git config/hook changes, and bounded path
evidence. The full suite passes 123 tests with the existing optional
`glas_harness` contract skip.

No current Activity Core/profile field supplies an authoritative path grant, so
the validator remains deliberately unwired. Metrics atomicity and required
close-evidence reconciliation also remain outstanding; T03 remains `wait`.

### Repository grant preparation — 2026-08-23

Added a parsed, versioned `repository_grant` v1 contract for `TaskSpec` inputs.
It requires explicit repository-relative path patterns, bounded positive commit
counts, `publish: false`, exact fields, and version `"1"`; it rejects unknown
fields, ambiguous types, duplicates, traversal/`.git` paths, and publication.
The canonical grant exposes a stable id and bounded path/policy digests and
translates directly to `RepositoryAcceptancePolicy`.

This is fail-closed preparation, not production enablement. A supplied grant
causes `run_task` to refuse before profile resolution or adapter dispatch, and
the Activity Core/issue-core adapters do not synthesize it from labels, prose,
`execution_refs`, or repo lookup. Existing grant-absent compatibility behavior
is unchanged. `docs/repository-grant.md` records the contract and the remaining
activation gates: authoritative upstream carriage, lease-bound transaction
wiring, accepted-result validation, and durable close evidence.
Thirty-three focused cases cover canonical identity/evidence, validator
translation, schema/type/path/commit/publication refusal, typed task-file
parsing, and proof that the runner neither dispatches an adapter nor mutates
the checkout.
Published at revision `8cb004a` with 156 passing tests and requested
authoritative-carriage review from Activity Core
(`28868534-031f-421d-a34a-a92b8429391d`) and profile-boundary review from
Glas (`e149c359-36bf-4867-ac10-f58a8f248666`). No execution enablement was
requested.

### Close-evidence outbox preparation — 2026-08-23

Added a production-inert `CloseOutbox` core for Activity Core completion and
failure intents. It stores private mode-`0600` JSON outside target checkouts,
keys entries by bounded run/transaction identity, uses a process-safe lock and
file/directory `fsync` around atomic replacement, suppresses identical pending
or delivered entries, and rejects conflicting identity reuse. Result evidence
is normalized and bounded by type, depth, collection/string/integer limits, and
a 64-KiB encoded ceiling.

Replay durably increments the attempt before calling a close-only callback,
moves success to delivered state, retains ordinary API failure with a bounded
error, and leaves process interrupts pending. Corrupt, oversized, or
directory/state-mismatched material is preserved with a reason in quarantine
and never delivered. Twenty-five focused cases cover private/atomic storage,
duplicate/conflict behavior, successful and failed replay, callback mutation,
interrupt persistence, corruption, atomic-write failure, two-process enqueue,
replay limits, and payload bounds.

`docs/close-evidence-outbox.md` records the storage/replay contract and the
network-ambiguity residual: a close request may be repeated after a timeout,
but replay never calls workload code and therefore cannot duplicate the
repository commit. The live claim loop remains unchanged pending transaction
wiring, Activity Core repeat-close review, and operator status/replay controls.
Published at revision `c97e5ea` with 181 passing tests and requested Activity
Core review of exact-repeat versus terminal-result reconciliation, conflicting
terminal evidence, and expired-lease behavior in message
`1c13bfb1-9015-4b8a-8b30-ee748c1d8dc5`. No claim-loop or deployment change
was requested.

### Local grant activation and metrics atomicity — 2026-09-04

Enabled the reviewed v1 `repository_grant` for local `TaskSpec` files now that
T02 supplies the lease-bound transaction. Successful granted runs validate the
exact commit count/ancestry, changed paths, clean post-state, protected Git
metadata, and remote-tracking refs before reporting success. Their bounded
transaction evidence includes grant and acceptance identities without raw
grant paths, prompts, or provider output. Adversarial runner coverage rejects
out-of-grant commits.

Chose the durable-external metrics branch of ADR-002's T03 decision. Granted
runs cannot use `--no-metrics`; they atomically append a kaizen-compatible
record under private `REIN_AHARNESS_STATE_DIR` storage and regenerate a summary
plus projection descriptor without touching the accepted checkout. Ledger
corruption or persistence failure is terminal for the granted result. A future
kaizen-owned, separately granted projection may commit those files to the
instance; the rein does not invalidate its own accepted post-state. Legacy
grant-absent runs retain repository-local metrics during migration.

Full verification passes: `222 passed, 1 skipped`. T03 remains `wait`, not
`done`, on two verified Activity Core contract gaps at current main `b72fdb5`:
the queue schema carries no authoritative repository grant, and complete/fail
accept only an actively leased claimed row while normalized result storage
drops transaction/grant/acceptance identity. A response-lost retry therefore
returns an ambiguous 409 and cannot be safely treated as delivered. Requested
a separately typed grant field plus identity-preserving, conflict-detecting
terminal reconciliation in State Hub message
`6c4189a5-5971-4eb9-a7bd-62fe368f9a02`. Live outbox activation stays
fail-closed until that exact upstream contract is available.

## Remove tenant logic from the shared runtime

```task
id: REINAH-WP-0003-T04
status: wait
priority: high
state_hub_task_id: "f6c7f80c-3807-54ac-b44a-ef582433b927"
```

Inventory every profile-absent FI/Binky definition and its current owner,
schedule, input/output files, credential lane, completion event, commit/push
behavior, and rollback path. With Activity Core, kaizen-agentic, and tenant
owners, migrate the behavior into versioned profiles plus tenant-owned
blueprints/manifests or separately owned typed capabilities.

Replace substring/label routing and tenant-specific code in the core worker
with a generic, versioned selector. Preserve coexistence only behind an
explicitly dated compatibility flag until each live definition has passing
replacement evidence. In particular, eliminate implicit default push behavior
from shared runtime code; publication must be a named, separately granted
capability.

**Done when:** no new tenant requires editing `approaches.py`; every existing
FI/Binky definition has owner-approved replacement and rollback evidence;
production runs through generic selectors; tenant modules and hard-coded event,
path, and prompt conventions are removed or moved to their owning packages;
and the compatibility flag is disabled before deletion.

### Preparation — 2026-08-23

`docs/legacy-runtime-inventory.md` records the four profile-absent scheduled
definitions and the direct/issue-core compatibility surfaces from current code
and owner files. It identifies inputs, outputs, credentials, completion events,
commit/push behavior, retry posture, rollback material, and migration gates.
This is read-only preparation; T04 remains `wait` until T01 accepts ADR-002.

### Dated compatibility guard — 2026-09-04

Profile-absent `ops_run` dispatch now requires an explicit, non-expired ISO
date in `AGENT_HARNESS_LEGACY_APPROACHES_UNTIL`. Missing, malformed, or expired
values refuse terminally before target resolution or tenant executor dispatch.
Authoritative `harness_profile_ref` rows bypass the legacy registry and this
flag entirely. The deployment example currently declares `2026-12-31`, making
the remaining four tenant migrations visible and time-bounded rather than a
silent permanent default. Focused tests cover boundary-day, expired, malformed,
missing, and pre-dispatch refusal behavior.

Removed the FI compatibility executor's `git push origin HEAD` path entirely.
`FI_RESEARCH_BRIEF_PUSH` no longer widens behavior even when set; the executor
creates a local commit only. A regression test observes every Git invocation
and proves no push occurs. Any publication now requires a separate owner,
grant, and evidence contract.

T04 remains `wait`: the FI and Binky definition owners still need to move
their four scheduled behaviors to approved profiles/tenant-owned capabilities
before the compatibility flag and tenant modules can be removed. Requests:
Freedom Intelligence `d0b45acb-0002-405b-9620-cc44568170fb`, Binky
`c941f47b-d100-4df3-b4f4-feb1e187d2d8`, kaizen-agentic
`29a010f4-7a5c-42cd-a13e-3a13326f75ff`, and Glas
`e91f3f67-2d5d-4ad2-923c-431ebafed77e`.

## Align deployment, recovery, and conformance with the supported runtime

```task
id: REINAH-WP-0003-T05
status: progress
priority: high
state_hub_task_id: "c4a3f08f-2874-5672-9f29-aecddd697d90"
```

Choose and document the supported production topology from T01. If the host
user service remains authoritative, label the Kubernetes sleeper as packaging
smoke or remove it from runtime claims. If Kubernetes becomes authoritative,
provide real workspace, credential, shutdown, lease, sandbox, and recovery
semantics before cutover.

Make the selected deployment reproducible:

- install pinned, non-accidental Glas/sand-boxer/llm-connect contracts rather
  than relying on mutable sibling editable checkouts;
- preflight bubblewrap/AppArmor and the executable reachability contract when
  the local profile is enabled;
- provide status and recovery checks for claim health, lease expiry, an
  execution crash, an API-close outage, sandbox teardown, and outbox replay;
- run the real cross-package contract tests in CI without silently skipping
  because optional runtime dependencies are absent; and
- define release/version compatibility for the instance manifest, Glas
  contract, profile catalog, Activity Core schema, and deployment artifact.

**Done when:** a clean host or chosen cluster target can reproduce the pinned
worker from documented inputs; readiness fails before claiming if a required
runtime boundary is unavailable; recovery drills leave no held repo lock,
claimed row, orphan sandbox, or lost required evidence; and CI/release gates
exercise the same contract versions as production.

### Supported topology declaration — 2026-09-04

Selected the existing railiance01 user systemd service as the authoritative
production topology. It is the only runtime that owns real checkouts, private
state, worker credentials, heartbeats, and signal shutdown. The Kubernetes
Deployment is now explicitly labeled `packaging-smoke`; its source comments and
deployment guide state that `sleep infinity` is neither ready to claim nor a
failover worker and must never receive the Activity Core worker credential.

T05 remains `progress`. Reproducible pinned sibling packages, startup readiness,
recovery/outbox controls, and non-skipped cross-package CI still need
implementation; the currently catalogued local Glas profiles are also
operationally `blocked` on `GLAS-IN-0002`.

## Re-prove one governed profiled run and close residuals

```task
id: REINAH-WP-0003-T06
status: wait
priority: high
state_hub_task_id: "68a13c4f-0cc7-5d0b-917e-441164da8c84"
```

After T01–T05 and upstream `GLAS-IN-0002` are complete, coordinate one disabled,
bounded Activity Core definition against a disposable controlled repository.
The run must use an explicit versioned profile and attribution refs, cross the
declared sandbox execution boundary, dispatch the real rein/model route, and
produce only the granted commit/evidence.

Capture non-secret evidence for claim/lease ownership, actor, profile, rein,
model, tool profile, sandbox, transaction baseline, accepted commit and changed
paths, metrics/reporting reconciliation, completion state, sandbox teardown,
source-checkout immutability, and absence of leftover lock/task/runtime files.
Exercise one fail-closed negative case under the same deployed artifact. Do not
reuse the withdrawn historical isolation implication from the 2026-07-26
coarse proof.

Before finishing the workplan, hand every actionable leftover to a live owner
record with `origin: residual` and `origin_ref: REINAH-WP-0003` (or to an already
live canonical record with an explicit acknowledgement).

**Done when:** one current profiled run succeeds end to end, the negative case
fails before ungranted mutation, all cleanup and evidence checks pass, Activity
Core and Glas acknowledge the proof, documentation reflects the deployed
truth, and no residual exists only in prose.

## Overall acceptance

1. Every mutating run is repository-locked, lease-bound, baseline-aware, and
   accepted against explicit commit/path/post-state rules.
2. Required completion and metric evidence is reconciled without dirtying the
   checkout after acceptance or duplicating domain commits.
3. The strategic profile-driven path completes through its declared sandbox;
   no host fallback is introduced.
4. Shared runtime dispatch is tenant-neutral and publication is an explicit
   capability, not an implicit side effect.
5. Credential and enforcement ownership matches a recorded decision and the
   repo has an authoritative validated classification.
6. Production deployment, recovery checks, CI, package versions, and docs all
   describe and exercise the same supported topology.