#110 - v1.0.75 (JUGGLEDEFENSE): the sticky runtime snapshot — path-hash revision, debounced copies, verified self-heal - OSS-Singularity/zcode-dispatch - oss-oo

ClaudiuSchuster commented

2026-10-24 21:36:42 +00:00

Owner

Station catch-up ship: v1.0.75 JUGGLEDEFENSE has been running on the station since 2026-10-24 08:15 (install triple EXIT 0, JD75-OK canary). Validated by val-juggledefense (JD stamp, ACCEPT-class). This PR lands it on main as the v1.0.75 monotonic step.

ClaudiuSchuster added 1 commit

2026-10-24 21:36:42 +00:00

v1.0.75 (JUGGLEDEFENSE): the sticky runtime snapshot — path-hash revision, debounced copies, verified self-heal

Checks / Functional checks (pull_request) Failing after 18m42s

Details Explain this check

f72b8fbcd3

The 3.16.3 flip regressed the v1.0.15-era juggle defense into a
turn-death wave (2026-10-23, 48 specimens, deaths at 50-90k with the
Provider Registry error while creates passed). Root cause pinned in
zcode.cjs: the app-server stamps its provider-registry revision from
the RESOLVED PATH of its zcode-builtin.json
(zcode-builtin:<int>:<sha256(path)> — the day's alternating
f71b12e1…/60fc4ef0… are the 3.16.2/3.16.3 dir paths), the live file
mutates under running children (fs-watch + merge-back writes), and
the log-harvested entitlement push coin-flips between update-window
eras.

The cure (design contract, JD1-JD7):
- sticky.py: content-addressed immutable copies (mode 0444) of the
  newest runtime snapshot under <config-dir>/runtime-sticky/,
  adopted behind a two-observation debounce; never mid-flight;
  fail-open everywhere (VEE-6 law).
- spawns pinned to the copy via the env pair the app honors
  (ZCODE_BUILTIN_PROVIDER_CONFIG_FILE + personal, plus
  ZCODE_APP_VERSION from the copy's version dir) — a deliberate
  product override over stale ambient pins; the owner's
  builtin_provider_config config pin keeps winning.
- the create-time push re-anchors onto the sticky copy's computable
  path-hash revision (sticky.target_revision, bundled-int aware);
  only the basedOn anchor moves, the provider map stays
  content-sourced.
- the registry-race self-heal rides only the CHILD's own post-spawn
  line (path-hash proof — strangers rejected with a note) and
  re-targets at most ONCE per dispatch, then fails honestly; the
  v1.0.37 any-line heal stays verbatim when no snapshot resolves.
- belt stays pin-free: no env-side version pins anywhere; the
  derivation is the product's own seam (belt diff: 0 hits for
  ZCODE_APP_VERSION / ZCODE_BUILTIN_PROVIDER_CONFIG_FILE).
- suite: ALTERNATE-HASH, DEBOUNCE (transient + stable adopt),
  PUSH-TARGET, SELF-HEAL (accept / stranger-reject / retry-once /
  sticky-inactive v1.0.37-verbatim) legs; the v1.0.37 rebuild leg
  now relines the sticky target. install.sh FILES + Makefile
  py_compile carry sticky.py; README + docs/USAGE.md §30 document
  the class and the cure.

ClaudiuSchuster added 1 commit

2026-10-25 00:35:32 +00:00

test: settle the shared parent_cwd lock in the rig (CI run 1790 hardening)

Checks / Functional checks (pull_request) Failing after 20m38s

Details Explain this check

e09647eaf3

Two CI failures on f72b8fb (attempts 1 and 2 of run 1790) were the
same environmental race, not product defects: the rig's detached
children (a delivery's notify grandchild in the D-C twins leg, the
WAKE region's revival probes before wr-b) legitimately outlive
their ledger-settled moment, and the next leg's spawn on the SHARED
parent_cwd dies queued-busy (exit 3, "cwd is already driven") when
the runner's inter-leg gap is tighter than the holder's tail. The
product's requeue-next-tick behavior is correct and live-verified;
the rig assumed single-tick drain.

- wait_cwd_lock_free(): bounded cmdline-based settle on the cwd's
  one-driver lock (absent/torn/zombie holders read as free — the
  product reclaims those on acquire anyway).
- wk_dispatch() and the wr-b spawn settle on parent_cwd first
  (run 1790 attempt 2, the WAKE wr-b strike).
- the D-C twins leg drains a busy-requeued twin with up to two
  settled re-sweeps before asserting (run 1790 attempt 1; the leg's
  subject is bell_id keying, not single-tick drain).

No product code touched.

ClaudiuSchuster added 1 commit

2026-10-25 01:04:50 +00:00

ci: outlive a load-degraded runner — wr-b settle ceiling + job window

Checks / Functional checks (pull_request) Successful in 24m7s

Details Explain this check

4daf0d54da

Run 1800 (e09647e) got past the settled lock sites and died at the
wr-b fired-probe settle: the probe is a full detached dispatcher and
on the degraded runner its import+spawn+quota-death tail outlived the
90 s wait while the record stayed parked. The wider window matters
beyond one leg: the last fully-green run (1655, 2026-10-17) already
measured ~23 min of suite alone, and the runner has crawled ~30%
slower since — the 30-min job ceiling was killing correct runs on
load, not catching hangs (every leg keeps its own timeouts).

- wr-b fired-probe settle wait: 90 s -> 300 s (misread-crawl guard).
- check.yml job timeout: 30 -> 45 min, with the measurements in a
  comment for the next soul who calibrates.

ClaudiuSchuster merged commit 55d312550c into main

2026-10-25 01:39:21 +00:00

ClaudiuSchuster referenced this pull request from a commit

2026-10-25 01:39:21 +00:00

v1.0.75 (JUGGLEDEFENSE): the sticky runtime snapshot — path-hash revision, debounced copies, verified self-heal (#110)

Rows
Columns

v1.0.75 (JUGGLEDEFENSE): the sticky runtime snapshot — path-hash revision, debounced copies, verified self-heal #110