runtime-activation-claim

name	runtime-activation-claim
description	Use when making any "X is enabled" / "feature X works" / "cache works" claim in a running session — requires runtime probe output from the standard harness startup path, NOT a launchd/cron test that explicitly sets the activation env var.

Runtime Activation Claim

The rule

Before any claim of "feature X is working" / "cache enabled" / "warmup completed" / "feature flag is on":

1. Read the activation function source — find enabled(), is_ready(), is_active(), or equivalent property on the relevant class.
2. Identify every gate the function checks (env vars, sys.modules probes, config flags, runtime state).
3. For each gate, state what it requires — name the env var, expected value, runtime precondition.
4. Run a probe in a CLEAN subprocess with NO env override:

   python3 -c "from <module> import <Class>; print(<Class>().enabled)"
   

5. The probe output MUST be True before claiming the feature works.
6. Quote the probe output verbatim in the claim.

Banned patterns

• "Cache works" based on launchd/cron test logs where the launchd env set the activation var.
• "Feature X works" based on a CI run where the env was set via with mock.patch.dict(...).
• "Warmup completed" based on _init_event.wait() returning (it is set at init, not at warmup completion).
• "enabled=True" based on reading the source code without running it.

Common multi-gate features in this repo

Feature