digital-garbageandClaude Opus 5
def940d9d5
Catching a modifier that fails to INSTALL was never the hard part. The one that costs a rental is the hook that works at step 0 and raises at step 3, after the GPU time is spent -- which the Detail modifier does on any video latent, because core's sharpen kernel cannot take a 5-D tensor. A module is now handed a patcher that guards every hook it installs, so it does not opt in to being safe: a module that could forget to is a module that can break the foundation. A hook that raises is dropped for the rest of that run, reported once with its traceback, and sampling continues. Thirty steps on the latent that used to end the run now complete untouched. Recorded per RUN, not per process, so a long session reports every generation that went inert instead of only the first after a restart. Full control turns all of it off. A one-step schedule, a width the model cannot use, a modifier that throws -- someone exploring the edges wants the real behaviour and the real traceback, not a careful refusal. One switch rather than one per guard, because a half-disabled safety net is harder to reason about than either extreme. It is asked for by capability, so nothing names the module that answers, and a build without it installed has nobody saying yes -- which reads as guarded. Honest about its own limit: a hook shape with no known neutral result is installed unguarded and named in the status, rather than counted as safe. Two test faults fixed while writing this. The assertions compared conds_out against the list passed in -- the same object the hook mutates -- so they were true whatever the hook did. And the registry fakes were hand-rolled and missing methods the real one has, which passed until the code called one. They use the real Registry now. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
48 lines
1.9 KiB
Python
48 lines
1.9 KiB
Python
"""Full control: the foundation stops protecting you, and says so.
|
|
|
|
The foundation's job is that nothing it does can produce a bug on its own --
|
|
values that cannot work are refused before a run starts, and a module that fails
|
|
mid-run is dropped rather than taking the generation with it.
|
|
|
|
Both of those are in the way when the point IS to see what happens. A one-step
|
|
schedule, a width the model cannot use, a modifier that throws -- someone
|
|
exploring the edges wants the real behaviour and the real traceback, not a
|
|
careful refusal. So this turns the guards off wholesale.
|
|
|
|
It is one switch, not a switch per guard, because a half-disabled safety net is
|
|
harder to reason about than either extreme: you would never know which refusal
|
|
you were still getting. And it defaults to off, because the surprising direction
|
|
has to be the one you asked for.
|
|
|
|
Nothing here silently changes behaviour: every guard that steps aside says that
|
|
it did, and every run made with this on carries it in the status.
|
|
"""
|
|
|
|
ID = "full_control"
|
|
TITLE = "Full control"
|
|
MOUNT = "settings.general"
|
|
STAGE = "load"
|
|
STATUS = "proven"
|
|
|
|
SETTINGS = {
|
|
"enabled": {
|
|
"type": "bool", "default": False,
|
|
"label": "Full control",
|
|
"hint": "Stop refusing settings that look wrong, and let failures surface. "
|
|
"Anything that breaks from here is yours to keep.",
|
|
},
|
|
}
|
|
|
|
# The one place that decides what "on" means, so no caller can get the key or
|
|
# the default subtly wrong -- and offered as a CAPABILITY rather than imported,
|
|
# so nothing else has to name this module to ask. A build without it installed
|
|
# simply has nobody answering, which reads as guarded: the safe direction.
|
|
def is_on(settings) -> bool:
|
|
return bool(((settings or {}).get(ID) or {}).get("enabled", False))
|
|
|
|
|
|
WARNING = ("full control is ON: nothing is being refused or guarded, and any "
|
|
"consequences of these settings are yours")
|
|
|
|
PROVIDES = {"guards_off": is_on}
|