fix(runtime): virtual tags hold on Bad inputs and inherit the worst input status (archreview 02/S14)

docs/ScriptEditor.md

@@ -399,6 +399,29 @@ reference map identically, so their plans stay byte-parity.
 
 ---
 
+## Input quality: what a script sees, and when it runs at all
+
+The rule is stated once, in
+[`docs/DriverLifecycle.md` §"The quality contract"](DriverLifecycle.md#the-quality-contract), and it
+applies identically to virtual-tag scripts and to `Calculation` driver scripts — they share
+`VirtualTagContext` and this editor, so one policy keeps this page true for every `ctx.GetTag` call
+site.
+
+- **`ctx.GetTag(path).StatusCode` and `.SourceTimestampUtc` are real.** The read cache used to stamp
+  every dependency `Good` with an evaluation-time timestamp, so a quality-aware script could not be
+  written at all — it was told Good even for an input whose driver had stopped communicating.
+- **A script is NOT run while any of its declared inputs is Bad.** The tag instead reports that
+  input's own status (`BadNoCommunication`, `BadWaitingForInitialData`, …) carrying its last known
+  value. So the `(double)ctx.GetTag("x").Value` idiom is safe against a dead input: the script simply
+  does not run, rather than throwing on every trigger and filling `/script-log`.
+- **An Uncertain input IS passed to the script**, and the output inherits that Uncertain sub-code. An
+  Uncertain value is present and a script can make a qualified decision from it; that is the alarm
+  engine's long-standing rule, now shared.
+- **The output never reports better than its worst input.** A Good result over an Uncertain input is
+  published Uncertain; nothing is published Good while an input is Bad.
+- ⚠️ **If you wrote a script that deliberately handled `null` for a dead input, it no longer runs
+  while that input is Bad.** Assume your inputs are usable — the runtime has already decided they are.
+
 ## Known Limitations / Follow-ups
 
 - **Tag-path completion shows resolvable keys only.** Surfacing the UNS browse