I read this as a read-only systems/code audit - I’ll reconstruct the v5 failure from captured evidence, measure current inotify capacity and pressure without altering state, then specify an event-driven bounded-watch replacement and regression acceptance criteria.


The captured failure is now localized to observer arming, not the golden-path logic: the subprocess reaches `ProductionCommitObserver.arm()` and fails before the first mutation. I’m tracing the observer’s actual kernel call and contract tests next, and reconciling the one-watch request against live UID-wide pressure.


I read this as a read-only root-cause audit - the evidence supports a real observer-arm failure, but not deterministic inotify exhaustion.

## Diagnosis

The failing gate was:

`tests/gateway/test_source_golden_path_verifier.py::test_driver_bundle_passes_native_verifier_with_terminal_inventory`

It launched:

```text
python scripts/source_golden_path.py \
  --source /home/cube/.cache/task26-strict-successor-1786976146/src-p \
  --evidence-root /tmp/pytest-of-cube/pytest-387/test_driver_bundle_passes_nati0/bundle
```

The exact failing operation was effectively:

```c
fd = inotify_init1(O_CLOEXEC | O_NONBLOCK);  // succeeded

inotify_add_watch(
    fd,
    "/tmp/pytest-of-cube/pytest-387/test_driver_bundle_passes_nati0/"
    "bundle/data/onboarding/telegram-customer-bootstrap-v1",
    392  // IN_CLOSE_WRITE | IN_MOVED_TO | IN_CREATE
);
```

This follows directly from:

- `source_golden_path.py:374-375`: one `watched_paths` entry, `ledger.json`.
- `gateway/commit_observer.py:73-80`: watches `path.parent`.
- The failure being `inotify_watch_failed`, rather than `inotify_init_failed`.

### Cardinality and capacity

- Requested files: **1**
- Unique parent directories: **1**
- Requested kernel watches: **1**
- Recursive tree watches: **0**
- `max_user_watches`: **131,072**
- Observed/live watches: **130,964**
- Numerically available: **108**
- Inotify instances: **47 of 128**, leaving **81**

Two consecutive read-only live snapshots remained at exactly 130,964. The five largest holders account for 130,785 watches, led by the same `senpi` processes recorded in `FAIL-CLOSED.json`.

### Determinism

The failure is **not deterministic under the measured pressure**:

1. One requested watch fits within the reported 108-watch headroom.
2. The v5 source Golden Path successfully armed the same one-watch observer at 17:36 and produced four valid commit receipts.
3. The isolated regression failed around 17:38.
4. The current pressure is still exactly 130,964, yet pressure alone does not mathematically force this one-watch call to fail.

The artifact discarded the underlying `errno`: `_os_error()` chained an `OSError`, but the driver serialized only `CommitObservationError: inotify_watch_failed`. Therefore it cannot distinguish `ENOSPC` from another `inotify_add_watch()` failure. Linux also defines `ENOSPC` as either quota exhaustion **or failure to allocate another required kernel resource**.

**Evidence-backed conclusion:** fail-closing was correct, but `FAIL-CLOSED.json` overstates the cause. It proves a failed `inotify_add_watch()` under high UID pressure; it does not prove exhaustion, and current pressure does not make the failure deterministic.

## Event-driven bounded alternative

Use Linux directory notification without inotify:

- Open each unique watched parent directory once.
- Configure `F_NOTIFY` with `DN_MULTISHOT | DN_MODIFY | DN_CREATE | DN_RENAME`.
- Select a queued real-time signal with `F_SETSIG`, block it before arming, and consume it through `signalfd`.
- Preserve the existing pre-block state replay and post-event byte/inode state comparison.
- Continue emitting the existing hash-chained `subscription_armed` and `commit_observed` receipts.

This remains kernel-event-driven, works for the synchronous atomic-replace/in-place commit patterns exercised here, requires no polling or sleeps, and consumes **zero inotify watches**. Resource use is bounded by unique parent-directory cardinality—one directory FD for this path.

## Bounded-watch regression acceptance criteria

1. The Golden Path uses exactly one notification resource for its one unique parent and zero recursive/tree watches.
2. Arming occurs before mutation and persists the same initial byte/inode state.
3. Atomic replacement produces exactly one contiguous receipt with the committed inode and SHA-256.
4. In-place synchronous commit produces the final closed commit hash, never an intermediate hash.
5. The existing arm-to-read race test passes through state replay without waiting for another event.
6. Multiple watched files sharing a parent still use one directory notification resource and route by post-event state comparison.
7. Unrelated sibling events cannot satisfy `observe()`.
8. Lost notification, malformed state, or timeout remains fail-closed.
9. Tests subscribe before triggering, await the exact event with a bounded timeout, and contain no sleeps or polling.
10. The 64-test source gate and installed equivalent pass unchanged while live UID inotify usage remains at current pressure.
11. Regression instrumentation asserts:
    - `inotify_add_watch` calls: **0**
    - directory notification resources: `len(unique(path.parent))`
    - this Golden Path’s bound: **1**

No files or processes were modified during this audit.