chore: delete committed build artifacts and retired campfire state (repo triage) - #7
Merged
Merged
Conversation
Repo triage 2026-07-29. Removes 197 git-TRACKED compiled build artifacts (.EXE binaries and generated Makefiles) under build-ci/, build-docker/, build-test/ and build-verify/, plus the 3 remaining .campfire/ files. Why these are safe: - The 197 build files were force-added in e7d8aa4 (2026-03-06) despite `build-*/` already being in .gitignore since before that commit. They are compiled output, not source. Verified: zero references to build-ci / build-docker / build-test / build-verify in any .yml, .sh, CMakeLists.txt or Makefile in the tree, so no CI job or build target consumes them. - .campfire/ is state for the coordination substrate retired in 2026-07 (CLAUDE.md documents the retirement; coordination moved to the Workflow tool + rd). Verified: zero references to ".campfire" anywhere in the repo. Every deletion is confined to build-*/ and .campfire/ — no file under src/, tests/, tools/, docs/ or distro/ is touched. tests/integration/ test_runtime_target.sh (the Rule 9 gate) passes unchanged. Also hardens .gitignore so the retired/scratch paths cannot be re-added: .campfire/, .telemetry/, scratchpad/, .ready/*.lock. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
baron-3dl
marked this pull request as ready for review
July 30, 2026 03:45
baron-3dl
added a commit
that referenced
this pull request
Aug 13, 2026
…byte-identical, zero-bash (CI gate) (#476) * vms-d1b: self-host spine #6 — MMK drives a real TCC compile in QEMU, byte-identical, zero-bash (CI gate) The shipped MMK.EXE now drives a REAL toolchain step inside OVMX in QEMU, against a real /dev/vms: it spawns a persistent DCL over VMS mailboxes and streams a descrip.mms whose action defines a foreign command TCC :== "$..." and invokes it to compile the REAL src/libvmssys freestanding runtime TU vms_string.c to an object. DCL activates the foreign command by fork()+execve() of the staged static TCC.EXE (a plain static image is not in-process-eligible, so imgact_activate returns SS$_UNSUPPORTED and DCL forks it) — the FIRST-EVER TCC.EXE run inside QEMU and the first time MMK drives a real compiler (not a DCL builtin) end to end. The parent (which never runs a compiler) asserts the driven object is a valid ELF relocatable carrying vms_strlen and is BYTE-IDENTICAL across two independent in-guest MMK-driven builds. Zero bash in the build path. This closes spine #6 (vms-d1b, the CI gate) and the MMK-driven-EXECUTION residual of spine #5 (vms-fe4) for the COMPILE stage. - tests/toolchain/mk_tcc_static.sh: builds tinycc as a PLAIN STATIC (musl) foreign-command image (distinct from mk_tcc.sh's IMGACT-packaged self-host image) — the binary DCL fork+execve activates, no IMGACT/shareable staging. - tests/toolchain/run_tcc_static_component.sh + CMake test toolchain-tcc-static-component: host proof the static TCC.EXE compiles the real runtime TUs (vms_string/vms_snprintf/driver) to valid, byte-identical objects; asserts vms_math.c is the documented x86 tcc-blocked TU (SSE "x" inline asm). - tests/qemu/test_syssvc_mmk_build.c: the QEMU suite (extends spine #4's test_syssvc_mmk_drive.c); honest-skips 77 with no /dev/vms. - tests/qemu/Dockerfile: stages static TCC.EXE at SYS$SYSTEM, tinycc's headers + musl's stdint.h closure beside it, and the real component source. The suite plugs into the STANDING kernel-executive CI barrier (builds the image from the checked-out tree, a clean context), so the MMK-driven native build is gated on every run — no new job. - facility_defects.sh: new per-facility control mmk-build-image-not-activated — dcl_exec_foreign_command reports success WITHOUT activating the image, so the driven TCC command completes but runs no compiler; reddens exactly the suite's five object/byte-identity assertions FAST (no $HIBER wedge), attributable to the build drive alone. A DEDICATED control, not a second suite on the sp_send=0 drive control: two ~50s $HIBER wedges do not fit run_tests.sh's 120s QEMU budget in one boot. Floor 96 -> 97. Verified in QEMU on this host: kernel-executive 76/76 (mmk_build 7/7); mmk-build-image-not-activated reddens exactly the 5 object assertions with no strays and the harness completes (no timeout); executive-absent mmk_build rc=77. BUILD.COM retirement is NOT done: the full compile->archive->LINK-to-image chain in-guest remains (vms_math not tcc-compilable on x86_64; LINK needs the SYS$LIBRARY shareables staged + logical-name resolution in LINK.EXE + IMGACT activation) — the precise residual for spine #7, documented in docs/design-self-host-spine5-mmk-component.md. No red gate shipped (Rule 6/7). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * vms-d1b: fix mmk_build CI timing — wait for MMK to EXIT (single generous bound), not a 2s reap grace CI's Kernel Executive job went red from a clean build: mmk_build produced the object and echoed the marker (build-#1 assertions GREEN) but MMK had not yet finished tearing down its spawned DCL within the tight 2s REAP_GRACE, so reap1 stayed 0, the reap1 short-circuit skipped drive #2, and the completion + byte-identity assertions reddened. CI's TCG is much slower than the dev host, where reap1 was always 1. Restructure drive_build to a SINGLE generous bounded wait (40s) that drains output (detecting the marker) AND polls for MMK to exit, returning the instant MMK exits -- so a green drive costs only its real runtime and the bound is only ever hit by a genuine hang. Removes the split 10s-marker / 2s-reap phases that were sized for a fast dev host. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * vms-d1b: make mmk_build load-robust — capture proof (marker+object) instead of waiting on MMK's exit The clean-build repro showed mmk_build's remaining flake was MMK's slow self-exit under contended TCG: the compile finished, the marker was echoed and the byte-identical object was on disk, but MMK had not yet torn down its spawned DCL and exited within the bound, so the reap-based assertion reddened. MMK's exit timing is not a property this suite tests. drive_build now stops the instant the PROOF is captured -- the DCL echoed OVMXD1B:COMPILED AND the object exists on disk -- and kills MMK as cleanup rather than gating on its self-exit. A genuine mid-drive $HIBER deadlock still fails hard (no marker is ever echoed). The completion assertion is now the marker (reliable), the reap-exit assertion is dropped, and the drive-#2 short-circuit is keyed on the object (robust under load), not on MMK's exit. The negctl declared set is unchanged (the 5 object/byte-identity assertions; the marker stays green). Verified: two consecutive clean green runs (mmk_build 6/6), and mmk-build-image-not-activated reddens exactly the 5 object assertions with the marker green. (A QEMU timeout / mmk_drive reap-flake seen intermittently here is this 10-container dev host's load, not the code: on CI the harness completed and mmk_drive passed.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: alice <alice@workspace.local> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
baron-3dl
added a commit
that referenced
this pull request
Aug 13, 2026
…e-identical, zero-bash (CI gate) (#488) Extends spine #6 (vms-d1b, MMK drives a real TCC COMPILE in QEMU) with the ARCHIVE stage. The shipped MMK.EXE now drives a real TWO-TU build over its persistent mailbox-driven DCL against a real /dev/vms: TCC.EXE compiles VMS_STRING.C + VMS_SNPRINTF.C (the two real src/libvmssys runtime TUs that ARE fully tcc-compilable on x86_64 -- vms_math.c's SSE "x"-constraint inline asm is not, so it is excluded) to objects LIBRARIAN.EXE /CREATEs OVMXRT.OLB from the two objects both driven as forked foreign-command IMAGES (fork+execve, like TCC.EXE), and the produced .OLB (a valid !<arch> object library carrying both members + vms_strlen/vms_snprintf) is asserted BYTE-IDENTICAL across two independent in-guest MMK-driven builds. Zero bash in the build path. Green in QEMU from a clean tests/qemu/Dockerfile build (12/0), wired into the standing kernel-executive CI barrier -- no new job. Finding: OVMXRT.MMS names the librarian foreign command `LIBR`, but `LIBR` abbreviates the built-in DCL LIBRARY verb (dcl_builtin.c min_abbrev=3), so DCL would run the in-process cmd_library() -- which resolves object names against the VMS default directory, not the fork's Linux cwd where TCC wrote them, and fails %LIBRARIAN-E-OPENIN. The in-guest MMS names it `LIBRARIAN` (9 chars, not a prefix of any built-in -> falls through to the foreign-command symbol and forks the staged LIBRARIAN.EXE), the exact trap OVMXRT.MMS already documents for `LNK` vs the built-in LINK, here for LIBRARY. Staging (tests/qemu/Dockerfile): build the vmslibrarian target static-musl and stage LIBRARIAN.EXE at SYS$SYSTEM beside TCC.EXE; stage VMS_SNPRINTF.C + its header in the component dir. Negctl: the existing mmk-build-image-not-activated control (dcl_activate_image -> SS$_NORMAL, foreign command reports success without running) now also reddens the six archive assertions (no driven TCC -> no objects -> LIBRARIAN has nothing to archive -> no .OLB); all six are declared in its knock_on_fail with an extended knock_on_why. Defect count unchanged (floor 97). HONEST SCOPE (Rule 6/7 -- no red gate, no premature retirement): this closes the COMPILE + ARCHIVE stages in-guest. The final LINK-to-runnable-image rung (LNK --executable --use the six OVMX shareables -> IMGACT activate -> image RUNS) is NOT driven here -- it needs the producer graph + IMGACT.EXE staged in the QEMU harness and the native-link+activate stack (host-proven by run_dcl_native.sh) reproduced under QEMU busybox. Tracked as vms-725. BUILD.COM therefore STAYS. Co-authored-by: alice <alice@workspace.local> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
baron-3dl
added a commit
that referenced
this pull request
Aug 13, 2026
…INK→ACTIVATE in QEMU (zero-bash CI gate) (#493) * vms-725: self-host spine #7 FINAL rung — MMK drives compile→archive→LINK→ACTIVATE in QEMU, byte-identical, zero-bash (CI gate) Extends spine #7 archive (vms-6be, #488) with the LINK-to-runnable-image rung. The shipped MMK.EXE now drives the WHOLE OVMX-native build chain over its persistent mailbox-driven DCL against a real /dev/vms, and the harness activates the produced image through IMGACT to its oracle exit: TCC.EXE compiles VMS_STRING.C + VMS_SNPRINTF.C + the driver OVMXRTRUN.C LIBRARIAN.EXE /CREATEs OVMXRT.OLB from the two runtime objects LINK.EXE --executable --use DECC$SHR.EXE links OVMXRTRUN.OBJ + OVMXRT.OLB into OVMXRT.EXE (selectively pulling VMS_STRING from the library) [activate] the harness fork+execs OVMXRT.EXE -> the kernel loads its PT_INTERP=/vms/.../IMGACT.EXE, which maps DECC$SHR from SYS$LIBRARY and binds the one cross-image import -> it RUNS to exit 216 (vms_strlen("OVMXRT")*36 -- nowhere else for 216 to come from) Every stage byte-identical across two in-guest MMK-driven builds. Green in QEMU: test_syssvc_mmk_build 18/0, from a clean tests/qemu/Dockerfile build. Self-host's final MMK-driven rung: MMK builds a real OVMX component to a running image entirely inside OVMX. Key findings / choices: - Only DECC$SHR is --use'd, NOT the "six shareables" the residual anticipated: the component is freestanding (its sole external symbol is vms_strlen, in the .OLB), so the executable's only cross-image import is crt0/exit from DECC$SHR. - The producer graph (IMGACT.EXE via src/imgact/Makefile; DECC$SHR.EXE via mk_decc_shr.sh whole-archiving musl libc.a + libgcc.a through the static LINK.EXE) BUILDS CLEAN in the ubuntu+musl-gcc Dockerfile -- the alpine-only assumption was unfounded. - `LNK`, not `LINK`: LINK IS the built-in DCL verb; LNK (not a prefix of it) falls through to the foreign-command symbol and forks the staged LINK.EXE -- the same trap as LIBRARIAN vs LIBRARY (vms-6be). The `$` in the absolute DECC$SHR.EXE --use path is an ordinary VMS filename char in the raw DCL tail. - vms_snprintf stays archive-only: TCC compiles its varargs to tinycc's __va_arg helper, which DECC$SHR does not export, so the runnable image pulls VMS_STRING only. The .OLB still carries both members (proven). Staging (tests/qemu/Dockerfile): build the static vmslink LINK.EXE + IMGACT.EXE (make ARCH=x86_64) + DECC$SHR.EXE (mk_decc_shr.sh); stage LINK.EXE/IMGACT.EXE at SYS$SYSTEM, DECC$SHR.EXE at SYS$LIBRARY, OVMXRTRUN.C in the component dir. Negctl: the existing mmk-build-image-not-activated control now also reddens the six LINK+activate assertions (no driven toolchain -> no image -> no exit 216); all declared in its knock_on_fail with extended knock_on_why. Floor unchanged. BUILD.COM STAYS (Rule 6/7). It is NOT cleared by this proof: it is still load-bearing for the S4 self-host FIXPOINT (run_link_selfhost_native.sh:136 copies + drives it multi-TU to build LINK.EXE gen2==gen3, a 1.0 gate) AND run_build_com_native.sh (S3.2). The vms-725 MMK chain builds a small 2-TU component, not the multi-TU LINK.EXE self-host fixpoint. Retirement waits on porting that fixpoint from BUILD.COM to an MMK descrip.mms -- tracked as vms-89d. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * vms-725: fix flaky mmk_build gate — run LINK+activate on one drive, raise per-drive bound The first cut wired the LINK+activate onto BOTH in-guest MMK drives. Under slow/ contended TCG that reddened intermittently: the 40s per-drive bound elapsed AFTER the archive but BEFORE the LINK (the drive was progressing, not wedged), killing MMK mid-drive; and two heavy full-chain drives pushed the whole suite toward run_tests.sh's 120s whole-VM budget. mmk_build passed 3x then failed once (7/11) — a Rule 8 flake, not shippable. Fix (mmk_build now 16/0 across repeated runs, whole VM 76/76 + green when the host has capacity): - Drive #1 is the lighter compile+archive drive (vms-6be); drive #2 runs the full compile→archive→LINK chain + activation. The compile+archive OUTPUTS are still asserted byte-identical across the two drives; the LINK runs once. - The LINK OUTPUT's byte-identity is proven byte-identical on the host (run_mmk_component_build.sh links the image twice, cmp-clean); in-guest the rung proves the driven LINK yields a real image that ACTIVATES and RUNS (exit 216) — the property that could not be shown before. This keeps the suite close to the vms-6be weight the kernel-executive barrier already carries reliably. - Per-drive bound raised 40s→60s so a slow-but-progressing full drive completes the LINK before cleanup. Negctl mmk-build-image-not-activated: the two dropped image assertions (build #2 / image byte-identity) removed from knock_on_fail; the four LINK+ activate assertions kept (produced / valid ET_DYN / PT_INTERP / activated 216), knock_on_why updated. Assertion set: 1 require + 14 knock = the 15 non-completion assertions. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * vms-725: shrink mmk_build to one runtime TU per drive — fit the 120s whole-VM CI budget CI revealed the real budget: the kernel-executive gate runs ~76 suites in ONE QEMU VM under run_tests.sh's fixed `timeout 120`, already near the edge on CI's slower runner. The prior cut's mmk_build PASSED on CI (16/0), but the VM then hit 120s during the very NEXT suite (test_syssvc_mmk_drive), and the qemu timeout (SIGTERM) reddened the whole run. My two-runtime-TU + LINK+activate suite was the tipping weight. Fix: each drive now compiles ONE runtime TU (vms_string), not two, making the suite LIGHTER than the vms-6be compile+archive suite (−2 heavy TCC compiles, + a cheap driver compile + fast LINK + instant activation). Kept: two-drive compile+archive byte-identity, the LINK+activate proof (drive #2), exit-216 activation. The archive is now single-member; LIBRARIAN archiving MULTIPLE members and the LINK output's byte-identity remain host-proven (run_mmk_component_build.sh). Assertion set: 1 require + 14 knock still equals the 15 non-completion assertions; negctl + docs updated to match. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: alice <alice@workspace.local> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
baron-3dl
added a commit
that referenced
this pull request
Sep 11, 2026
…ts-success-unstarted (33→32)
kernel-core/vms_cluster_fork_bind.c gets a real injected negative control (§1 33->32).
Defect fork-worker-start-reports-success-unstarted: vms_cluster_fork_worker_start()
short-circuits its (unique) exec_kthread_create with `0 &&`, so status stays 0
(success), ioworker_started is set and it returns SS__NORMAL — but the FC-P6.6 I/O
worker kthread is NEVER spawned ("reports success while doing nothing":
WORKER_START=1, IO_HANDLER_CALLS=0). Submissions still queue (io_sub stays green),
but no worker runs the blocking callback. suites_red: test_kmod_cluster_fork_hammer;
require_fail "the WORKER kthread really ran the blocking I/O callback ..." +
knock_on "THE FIX, MEASURED: the fork thread kept dispatching WHILE a served I/O
was blocking ..." (both anchored). Shares the suite with #6 (fork) but injected
separately, reddening a disjoint assertion pair.
Static-proven (host): selftest injects + idempotent-teeth; §1 drops
vms_cluster_fork_bind.c (33->32); dash -n clean; the escaped `0 && ` sed verified
to mutate exactly the create line. Per-defect QEMU falsification: batched local
rail run + CI negctl shard.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HMDFjHCqxDuXgbyxNU572h
baron-3dl
added a commit
that referenced
this pull request
Sep 12, 2026
…ts-success-unstarted (33→32)
kernel-core/vms_cluster_fork_bind.c gets a real injected negative control (§1 33->32).
Defect fork-worker-start-reports-success-unstarted: vms_cluster_fork_worker_start()
short-circuits its (unique) exec_kthread_create with `0 &&`, so status stays 0
(success), ioworker_started is set and it returns SS__NORMAL — but the FC-P6.6 I/O
worker kthread is NEVER spawned ("reports success while doing nothing":
WORKER_START=1, IO_HANDLER_CALLS=0). Submissions still queue (io_sub stays green),
but no worker runs the blocking callback. suites_red: test_kmod_cluster_fork_hammer;
require_fail "the WORKER kthread really ran the blocking I/O callback ..." +
knock_on "THE FIX, MEASURED: the fork thread kept dispatching WHILE a served I/O
was blocking ..." (both anchored). Shares the suite with #6 (fork) but injected
separately, reddening a disjoint assertion pair.
Static-proven (host): selftest injects + idempotent-teeth; §1 drops
vms_cluster_fork_bind.c (33->32); dash -n clean; the escaped `0 && ` sed verified
to mutate exactly the create line. Per-defect QEMU falsification: batched local
rail run + CI negctl shard.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HMDFjHCqxDuXgbyxNU572h
baron-3dl
added a commit
that referenced
this pull request
Sep 12, 2026
…ts-success-unstarted (33→32)
kernel-core/vms_cluster_fork_bind.c gets a real injected negative control (§1 33->32).
Defect fork-worker-start-reports-success-unstarted: vms_cluster_fork_worker_start()
short-circuits its (unique) exec_kthread_create with `0 &&`, so status stays 0
(success), ioworker_started is set and it returns SS__NORMAL — but the FC-P6.6 I/O
worker kthread is NEVER spawned ("reports success while doing nothing":
WORKER_START=1, IO_HANDLER_CALLS=0). Submissions still queue (io_sub stays green),
but no worker runs the blocking callback. suites_red: test_kmod_cluster_fork_hammer;
require_fail "the WORKER kthread really ran the blocking I/O callback ..." +
knock_on "THE FIX, MEASURED: the fork thread kept dispatching WHILE a served I/O
was blocking ..." (both anchored). Shares the suite with #6 (fork) but injected
separately, reddening a disjoint assertion pair.
Static-proven (host): selftest injects + idempotent-teeth; §1 drops
vms_cluster_fork_bind.c (33->32); dash -n clean; the escaped `0 && ` sed verified
to mutate exactly the create line. Per-defect QEMU falsification: batched local
rail run + CI negctl shard.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HMDFjHCqxDuXgbyxNU572h
baron-3dl
added a commit
that referenced
this pull request
Sep 14, 2026
…1244) Ground-verified against origin/main + the compat register; local checkout was stale. Wave C — status-line drift (body/register already showed the feature landed; header was stale): - design-authenticity-roadmap.md: "PROPOSED / no rd items exist" -> APPROVED/ACTIVE (vms-898/vms-6b8 funded, cited in the register). - design-files11-acp-executive.md: "design only, not yet built" -> LANDED (ACP model built; ods2.yaml vmsfs$runtime_fs implemented/real, ods2$reader verified/real; /vms passthrough retired vms-165). - design-libspawn-ovmx.md: "design only, no implementation" -> LANDED (async-AST/mbx prereqs + ovmx_spawn_pipeline.c/.h on main). - design-dcl-pipes.md: PIPE is real in dcl_cmd_process.c (pipe_split_segments), no longer a system() stub. - design-image-activation.md: correct §12 "symbol vectors not implemented" -> .vms$sv landed (vms-c65); delete the dead "Docker Mode" non-goal (Rule 9, one runtime = vms.ko/QEMU); retire the /vms/SYS0 passthrough install diagram (vms-165). - design-gcc-port-surface-gaps-register.md: banner the 2026-08-31 snapshot stale (predates the landed F2a host-surface trio); re-derive from the register. - design-alpha-crtl-archive.md: Option A landed (musl arch/alpha-dec-vms layer + mk_alpha_shr.sh on main), not "routing in progress". - design-mmk-exec-drive-ovmx.md: "BLOCKED as scoped" -> UNBLOCKED; design A prereqs landed, MMK drives compile->archive->LINK->activate in-guest (spine #6/#7). Wave D — internal pointer files + single-ledger + the draper security register: - internal/conductor-state.md + internal/lane-ownership.md: stale-snapshot banners (frozen at V0.5-5; latest is V0.6-16; lane-ownership still owns the deleted src/vmsscs/). Not refreshed to a fabricated "current" state, per the continuation-identity rule; corrected the dead vmsscs fact + noted the DECnet/self-hosting lanes. - qualifier-audit.md: hand table retired -> pointer to dcl-qualifiers.yaml (SSOT). - design-vms-parity-map.md: status/count tables retired -> compat register; narrative gap-analysis kept. - dcl-verb-fidelity-scoreboard.md: SNAPSHOT/should-be-generated banner -> the register owns verb/qualifier status. - draper-faithfulness-register.md (SECURITY): corrected the status column against origin/main code. RESOLVED (verified on main): SSH root-session cred drop (vms-49e, cred_drop.c), privilege-aware file access on the ACP path (vms-165 + acp_check_access), F$GETJPI lexical pid (vms_kif_getjpi_pid), process-control-by-PID (vms-904/dff7, resolve_control_target), sys$close indexed-file record loss (vms-5c6d, rms_idx_cleanup), XAB epoch (vms-3dd, unix_time_to_vms), invented STDRV line (vms-1fb), SHOW PROCESS LEF (vms-70eb/2b8), $HIBER/$SETPRI, and the re-armed DCL meta-facade tests (test_no_unix_leaks vms-fe21, test_mount, tautology family). Still live: logical-name split-brain for LNM$GROUP/JOB; residual uname()-sourced $GETSYI params. Left "status unverified -- re-check": SET UIC executive-visibility, on-disk Prolog-3/ISAM completeness (vms-890), STDRV phase-driver, and three remaining tautology tests. Co-authored-by: Claude Opus 4.8 (1M context) <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
1 participant
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.
Repo dead-weight triage, 2026-07-29. Deletions only — no source, no behavior change.
What this removes
build-ci/,build-docker/,build-test/,build-verify/.EXEbinaries + generated Makefiles, force-added ine7d8aa4(2026-03-06) even thoughbuild-*/was already in.gitignore. Verified zero references in any.yml/.sh/CMakeLists.txt/Makefile..campfire/.campfirerepo-wide.Plus
.gitignorehardening so these cannot recur:.campfire/,.telemetry/,scratchpad/,.ready/*.lock.Verification
build-*/and.campfire/— no file undersrc/,tests/,tools/,docs/ordistro/is touched (checked withgit diff --cached --name-only --diff-filter=D).tests/integration/test_runtime_target.sh(the Rule 9 gate) passes, all 5 checks.Context — this is one slice of a larger triage
Alongside this PR, on the working tree (not in this diff): 46 verified-merged worktrees and 60 zero-unique-commit branches were removed and regenerable build output deleted, taking the checkout from 3051 MB → 1561 MB. Two worktrees were held back because they carry uncommitted work — notably
work/vms-9f3with 20 stagedsrc/vmsscs/files.Not touched here, deliberately: the root
Dockerfile/docker-compose.yml. CLAUDE.md calls them dead legacy, but CI'sdocker-buildanduat-sessionjobs still depend on them —uat-sessionis currently the only SSH/DCL-login e2e coverage in CI. Removing them isvms-71a, gated onvms-02d(SSH on the QEMU runtime).🤖 Generated with Claude Code