I read this as a read-only invariant audit of the r24 launch failure - I’ll trace the authority loader and deployment surfaces, then return five falsifiable assumptions with minimal runtime queries and one decisive discriminator.


The failure point is now pinned: `capture_preflight()` constructs the production authority source, whose constructor unconditionally calls `chmod(0600)` on `runtime-authority.lock`; this occurs before `GlobalLedger.reserve()`. I’m checking the sealed live bindings and current service/mount observables so the assumptions are specific rather than generic.


I read this as an invariant-violation audit - here are five falsifiable assumptions and the decisive read-only discriminator.

The contradiction is: the lock is already valid at `0600`, but `FileCandidateAuthoritySource.__init__` still executes `chmod(0600)`. Linux rejects even a no-op chmod when the containing mount is read-only.

1. **A compliant existing lock makes authority loading observational.**

   Smallest query:

   ```bash
   PRE=/home/cube/.hermes/migrations/nutricoach-v1.5.0-combined/live-transaction-preseal-v15-runtime-authority-r24
   PYTHONDONTWRITEBYTECODE=1 PYTHONPATH="$PRE/controller-source:$PRE/dependencies/site-packages" \
   python -B - <<'PY'
   import inspect
   from gateway.platforms.task26_runtime_authority import FileCandidateAuthoritySource
   print(*[line.strip() for line in inspect.getsource(
       FileCandidateAuthoritySource.__init__
   ).splitlines() if "chmod" in line], sep="\n")
   PY
   ```

   - **True:** no output; an existing compliant lock is only validated/opened.
   - **False:** `self.lock_path.chmod(0o600)` appears.
   - **r24:** false.

2. **The production lock actually requires permission repair.**

   Smallest query:

   ```bash
   AUTH=/home/cube/.hermes/runtime-authority/dualcoach-v1.3.0-owner-risk-first-customer
   stat -Lc '%F mode=%a owner=%U links=%h' "$AUTH/runtime-authority.lock"
   ```

   - **True:** mode, owner, type, or link count violates the private-lock contract.
   - **False:** `regular empty file mode=600 owner=cube links=1`.
   - **Observed:** false; the lock is already `0600`, owner `cube`, link count 1.

3. **The exact live sandbox exposes the authority root writable.**

   While the sandbox process exists:

   ```bash
   nsenter -t "$LIVE_PID" -m -- \
     findmnt -T "$AUTH/runtime-authority.lock" -no TARGET,OPTIONS
   ```

   - **True:** the covering mount includes `rw`.
   - **False:** it includes `ro`.
   - **r24:** false. The launcher applies `--ro-bind / /` and writable rebinds only the profile, user-systemd, and migration trees; the sibling `.hermes/runtime-authority` tree remains under the read-only root bind.

4. **Rehearsal reproduces the production mount contract.**

   ```bash
   for spec in "live:$LIVE_PID:$AUTH" "rehearsal:$REHEARSAL_PID:$REHEARSAL_AUTH"; do
     IFS=: read -r name pid root <<<"$spec"
     printf '%s ' "$name"
     nsenter -t "$pid" -m -- findmnt -T "$root/runtime-authority.lock" -no OPTIONS
   done
   ```

   - **True:** both report the same effective writability, particularly both `ro`.
   - **False:** live reports `ro`, rehearsal reports `rw`.
   - **r24:** false; writable rehearsal clones masked the constructor’s metadata write.

5. **The failure remained before authorization and service mutation.**

   ```bash
   LEDGER=/home/cube/.hermes/migrations/nutricoach-v1.5.0-combined/live-authorization-v15/nutricoach-v150-v15-runtime-authority-r24
   EXEC=/home/cube/.hermes/migrations/nutricoach-v1.5.0-combined/live-executions-v15/nutricoach-v150-v15-runtime-authority-r24
   stat "$LEDGER/authorization-reserved.json" \
        "$LEDGER/authorization-consumed.json" \
        "$EXEC/phase.json" 2>&1
   systemctl --user show hermes-gateway-dualcoachtest.service \
     -p ActiveState -p SubState -p MainPID -p ExecStart
   ```

   - **True:** all three files are `ENOENT`; service is `active/running` with ExecStart under predecessor runtime `6c9c4394-v132`.
   - **False:** any ledger/phase file exists, or the service is inactive or points at successor `abf4366c-v150`.
   - **Observed:** true; predecessor PID `4174948` remains active on `6c9c4394-v132`, with no r24 ledger or phase artifacts.

**Single most decisive query**

Run this inside the exact live mount namespace:

```bash
nsenter -t "$LIVE_PID" -m -- sh -c \
  'stat -Lc "mode=%a owner=%U links=%h" "$1"; findmnt -T "$1" -no TARGET,OPTIONS' \
  sh "$AUTH/runtime-authority.lock"
```

The decisive failure signature is:

```text
mode=600 owner=cube links=1
/ ... ro,...
```

That simultaneously proves the lock already satisfies the security invariant and the loader’s unconditional chmod cannot succeed in the production namespace.