operational-rigor: an interactive path is unverified until driven in its runtime#45
Merged
F-e-u-e-r merged 3 commits intoJul 20, 2026
Merged
Conversation
firaen22
force-pushed
the
interactive-runtime-unverified
branch
from
July 19, 2026 00:53
d1e0cbe to
2a0341f
Compare
…in its runtime Client-runtime behavior that turns on framework identity or lifecycle (callback identity across renders, ref mount/unmount timing, effect dependency capture) can pass every local gate AND a cross-family diff review yet break only once deployed — the fault lives in runtime interaction the static artifact never exercises, so a green build, clean diff, and passing unit tests are all silent on it. Names the class as a §4 rule (the existing "verify by execution; if impossible say what to run" covers the principle but not this class), with the honest disclosure: treat a freshly-shipped interactive path as unverified until driven where it runs. Provenance: generalizes a private production incident (contributor-reported shape); ships `unprobed` — the pack's private fixtures have no interactive arm (cf. the grill-pass note). Marker records the debt, not an exemption. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
firaen22
force-pushed
the
interactive-runtime-unverified
branch
from
July 19, 2026 06:04
2a0341f to
b113871
Compare
…l xcheck Addresses grok-4.5 (high) + gpt-5.6-sol (max) review of firaen22's rule. Both families independently flagged the same merge-blocker: the done-condition was dual-armed (drive OR disclose) but only the ✅ modeled the disclose arm and the body never ordered the arms like parent §4 - a weak model could ship+disclaimer without driving even when a runtime was reachable. Fixes, all reproduced against the file's own doctrine: - Order the duty to §4's execute-or-say: drive the relevant lifecycle sequence (re-render/mount-unmount/dep-change) in a faithful runtime and observe the result when one is reachable; disclosure is the fallback ONLY when it is not. - Rewrite ✅ to show drive+observe (was: a bare disclosure); ❌ now covers both unit-green-so-works AND disclosed-when-a-runtime-was-reachable. - Soften the overstated absolute (gpt FIX-1 / grok nit): 'every static gate / none can surface / only real runtime' was false - a re-render component test or a dependency lint catches SOME; the true claim is a gate that does not exercise the transition cannot establish it. - Wording: 'depends on' not 'turns on'; 'new or changed' not 'freshly-shipped'; a local runtime example instead of 'deploy target' (that bleeds into external-systems); one-way cross-ref to delegation-and-review §3 unit-green so a later editor won't merge the homes. Runtime examples kept brand-generic per skill-authoring §6. unprobed marker + Provenance unchanged (still accurate under the softened claim). Word-diff audited vs b113871: zero unintended dropped clauses. Local checks green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gpt-5.6-sol (max) round-2 caught two refinements of the round-1 fix
(grok round-2 PROCEEDed); both reproduced, non-thrashing:
- 'tests that don't drive it stay silent' slipped back toward the
absolute the round-1 fix shed: a non-driving test/build may catch
OTHER defects, it just can't certify this transition. Reworded to the
non-establishment claim ('may catch other defects but can't certify
this one'; 'exercise-the-transition, not distrust-every-test').
- The fallback overcorrected: 'disclose ONLY when no faithful runtime is
reachable' forbids the legitimate case where a runtime IS reachable but
the transition can't be driven (state/credentials/hardware) — which
conflicts with parent §4's 'if impossible, say so'. Re-keyed to whether
the transition can be driven+observed in any reachable runtime, with the
escape hatch still closed ('never merely because a reachable one was
skipped' + the ❌ arm).
Word-diff scoped to those two spots; ✅/❌ and the unit-green cross-ref
(grok-PROCEEDed) untouched. Local checks green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Names a class the existing §4 rules cover only in principle: an interactive or client-runtime path is unverified until driven in its real runtime. Client behavior that turns on framework identity or lifecycle — a callback's stable identity across renders, a ref's mount/unmount timing, an effect's dependency capture — can pass every static gate (unit tests, the build, a cross-family review of the diff) and still break in a way none of them can surface; only driving the path in its real runtime exercises the fault. Adds the honest-disclosure rule (treat a freshly-shipped interactive path as unverified until exercised where it runs) with a ✅/❌ pair, plus a Provenance entry.
Why
The existing §4 line "verify by execution wherever possible; if impossible, say so and state what the user must run" states the principle but never names this class, and the failure is counter-intuitive: a green build, a clean diff, and passing unit tests are all silent on it because the fault lives in runtime interaction the static artifact never exercises. An operator reads "diff reviewed clean + tests pass" as done and ships an interaction that only breaks under a real click on the real deploy target. The nearest existing homes are adjacent but distinct:
references/external-systems.md's deploy-target contract is about serverless fire-and-forget (server side), not client-runtime identity/lifecycle; §4's execute-or-say-what-to-run is the general rule this sharpens.Provenance
Generalizes a private production incident (contributor-reported shape; the private repo is verifiable by the contributor, not linkable here) per the README covenant's private-evidence-as-shape branch. Ships with an in-body
unprobedmarker: the pack's private fixtures have no interactive arm to drive it — the same gap the existing grill-pass Provenance note already records — so the marker records the debt, not an exemption.Self-check
operational-rigor's own rules individually against the addition: no model/tool/repo names in rule text (framework named only by generic shape — callback identity, ref lifecycle, effect capture — not by product), observable/checkable claims only, ✅/❌ present, added lines within the file's width convention, 0 invisible-unicode (swept), straight apostrophes/quotes per house convention (53:0 / 48:0).references/external-systems.mddeploy-target (server-side), delegation-and-review §2 packet-review and §3 unit-green-is-not-integration (review of others' work / unit-vs-integration seam) — none is this client-runtime-vs-deployed-runtime home.Diffstat
+21/−0, one file (
skills/operational-rigor/SKILL.md): the §4 rule (+14) and its Provenance entry (+7).