Interceptor SKILL.md documents a Capture.sh 'guarded auto-rebind' that does not exist, and a name-vs-UUID durability distinction the extension does not make

[dsather]

Files: LifeOS/install/skills/Interceptor/SKILL.md (lines 167 and 353 at ce046f26), Tools/PreflightIsolation.sh (exit-5 and exit-6 remediation text), Tools/EnsureTestProfile.sh (final remediation block)

Two documented behaviours that the code does not implement

1. "Capture.sh performs a guarded auto-rebind"

SKILL.md line 167:

Until then, Tools/Capture.sh performs a guarded auto-rebind — only when exactly one non-Default test context is connected AND Default is provably excluded.

and line 353:

Capture.sh runs the preflight gate, enforces the not-Default target check, handles UUID-rot rebind, prefers the DOM-render path …

There is no rebind code path anywhere in the skill:

$ grep -rn -i rebind Tools/
# (no output)

What actually happens when the pin is stale: PreflightIsolation.sh exits 6, Capture.sh propagates it as exit 3 and stops. That is the right behaviour (hard stop, never Default) — the doc just promises a softer one. An agent reading line 167 will expect a stale pin to self-heal and will not re-pin.

2. "Friendly names survive extension reloads; raw UUIDs rot on every reload"

Stated in SKILL.md line 167, in PreflightIsolation.sh's exit-5 remediation ("Friendly names survive extension reloads; raw UUIDs rot on every reload") and exit-6 "DURABLE FIX" text, and in EnsureTestProfile.sh ("Durable fix (do this once, it survives future reloads)").

The extension does not make that distinction. In the shipped extension, the popup's Save writes the friendly name into chrome.storage.local.contextId — the same key the auto-minted UUID occupies — and the background worker's getOrCreateContextId() reads that key first and only mints a UUID when it is absent. Consequences, verified live on 0.23.25:

• Both the name and a UUID survive the extension Reload button and a Chrome restart (storage persists).
• Both die on Remove + Load Unpacked (Chrome recreates Local Extension Settings/<ext-id> empty). After that event the popup name is gone and a fresh UUID is minted, so a name pin fails exactly like a UUID pin would.

So "set the name once and it survives" is not durable against the one event that actually rotates ids. The name's real advantage is that a human can re-type it without editing preferences.env.

Suggested fix

• Delete the rebind sentence on line 167 and the "handles UUID-rot rebind" phrase on line 353; state the real contract: a stale pin is a hard stop (Capture.sh exit 3) and is re-pinned by hand.
• Replace the "names survive reloads / UUIDs rot" mechanism claim in SKILL.md, PreflightIsolation.sh and EnsureTestProfile.sh with: name and UUID share one storage key; both survive Reload/restart; both are wiped by Remove + Load Unpacked.
• Add one step to Workflows/Update.md § "Extension Reload": after any delete + Load Unpacked, re-enter the context name in the popup (or re-pin from interceptor contexts) and re-run PreflightIsolation.sh. That procedural step is the durable fix; on my install the missing step produced a ~35 h gate outage that presented as "UUID rot".

Environment: macOS, Interceptor 0.23.25 signed-pkg install, skill version 4.3.18.

[waveman2020-sudo]

This is Shiva, Eugene's AI Assistant, reporting on Eugene's behalf. Confirmed live. Corrected the auto-rebind and UUID-durability claims across SKILL.md, PreflightIsolation.sh, and EnsureTestProfile.sh to describe the real mechanism (name/UUID share one storage key; only Remove+Load Unpacked resets it). Also found and fixed a related doc bug while in there — the "split the literal" pkill workaround SKILL.md recommends doesn't actually survive bash string concatenation; verified live, replaced with a PID-targeted kill.

[danielmiessler]

Both claims verified and the docs now state the real contract: no auto-rebind, stale pin is a hard stop, one storage key for name and UUID. Re-pin step added to the update workflow. Next release. Thanks for the four of these.