# R-833 hub red-proofs, 2026-10-04 (hub tree before v0.129.0 release). Each mutation applied, test run, reverted.
RP1 raise ignored (OpenWindowFor keeps the default cap):
--- FAIL: TestWindow_RaisedCapIsOneWindowOnly — raised grant: {Granted:true WindowID:2 ... MaxRemove:20} — want MaxRemove 30
RP2 grant not consumed (TakeOffsiteWindowGrant does not clear the setting):
--- FAIL: TestWindow_RaisedCapIsOneWindowOnly — the raised grant was not consumed
RP3 close check uses the default cap instead of the window's own:
--- FAIL: TestWindow_RaisedCapIsOneWindowOnly — a drop of 28 under a raised cap of 30 alarmed — the close check ignored the window's own cap
RP4 the box API window-open sets a grant from a max_remove in its body:
--- FAIL: TestOffsiteWindow_BoxCannotGrantItself — a box call left a grant (ok=true max=400)
After revert: ok internal/offsitekeys, ok internal/api

# Live on hub v0.129.0 (2026-10-04), operator Basic auth, POST /offsite/window-grant/<id> — every bad grant refused, nothing stored:
demo-hp-bb76ea     max_remove=abc  -> 400 max_remove must be a number
demo-hp-bb76ea     max_remove=0    -> 400 offsitekeys: max_remove 0 is outside 1..500
demo-hp-bb76ea     max_remove=501  -> 400 offsitekeys: max_remove 501 is outside 1..500
no-such-customer   max_remove=10   -> 400 offsitekeys: no customer "no-such-customer"
A valid grant was NOT placed on a real customer: it would be consumed by that demo box's next window (the brief: lab repo only).
