ix

index is no longer a submodule: one repo, and nothing left to bump

Fri, 31 Jul 2026 09:05:00 GMT

index is no longer a submodule: one repo, and nothing left to bump. ix vendored index as a git submodule at ./index and consumed it as a flake input. Two pointers named the same code: the gitlink and the rev in flake.lock. Keeping them agreeing needed a bot, a rolling bump pull request, a watchdog, a repair-PR bot, a pre-commit guard, a pre-push guard and a fixture suite for the guards. That is gone. index/ is ordinary tracked files in ix, and its history came with it, so git log -- index/... works and git blame reaches back through the join. ## What you have to do Pull. git submodule commands against ix now do nothing, and a stale .git/modules/index is harmless. If a script of yours runs git submodule update --init against an ix checkout, delete the line rather than leaving a step that cannot fail. Nothing about building changes. flake.nix still says index.url = "path:./index". ## Why the pointer was the whole problem A path: input to a submodule records the submodule's revision: A path: input to a plain tracked subdirectory does not: No rev, no narHash. There is nothing to move and nothing that can disagree, so the machinery that existed to move it has no job. Retired with it: submodule-lock-sync.yml and its repair bot, check-submodule-lock-sync.sh and its fixture suite, the escalate watchdog for index bumps, index's sync-ix-submodule.yml dispatch, and the repository_dispatch bridge job. The lock guard is worth a note. Once the rev is gone it selects on locked.type == "path" and locked ? rev, matches nothing, and prints flake.lock agrees with every gitlink pin on every run, having compared nothing. It was deleted rather than left wired to an empty set. If you write a successor, give it something external to check against: a consistency check between two values we control cannot catch a fault that moved both, which is how a flake.lock pinning a revision that does not exist in any repository passed the guard on its way to a push. ## The window this closes The bump loop's most recent pull requests took 10 and 22 hours against 3 to 8 minutes in early July. During one of those windows ix's gitlink sat 92 commits behind index main, so a merged index change had no path to a machine for most of a day. ## What is not done The public indexable-inc/index repository is still writable and still the development history. Turning it into a read-only projection of ix:index/ is a separate change. Until it lands, treat index as frozen: commit in ix.

A cancelled apply used to brick the regional evaluator, and the resolve line never said so

Fri, 31 Jul 2026 02:45:00 GMT

A cancelled apply used to brick the regional evaluator, and the resolve line never said so. Pressing Ctrl-C during ix apply could leave the region's evaluator unusable until someone removed a file by hand. One did, on 2026-07-30 at 18:31 UTC, and every apply from that account failed for the next four hours with a Nix trace that blamed the operator's flake. The evaluator holds a warm Nix store on purpose, so whatever a cancelled run leaves behind outlives it. What it left behind was shallow.lock in the git cache, and a zombie nix process still unreaped 4h41m later. Nothing held the lock; the process that wrote it had died mid-fetch. Cancelling drops the host side of the stream and signals the guest nothing. GuestExecStream has no Drop, so the socket just closes; in the guest, handle_streaming propagated the failed write out through ?; and Child::drop neither kills nor reaps. The child ran on unsupervised until its own pipes broke, and git, killed mid-fetch, never removed its lock. StreamingChild now terminates and reaps on every exit path out of that function, signalling the process group rather than the child, because nix spawns git and signalling only nix leaves the fetch holding the lock. SIGTERM first with a grace period, then SIGKILL: the grace is load-bearing rather than polite, since git unlinks its locks from a handler and cannot from SIGKILL. The first version of that fix was wrong in a way worth repeating. Rust drops locals in reverse declaration order, so a guard declared before the pipe readers runs after them: the tree lost stdout and stderr first, took SIGPIPE, and died without running any handler. It reproduced the original defect through a different door while appearing to work, and only the regression test said so. The guard owns the pipes now, so the ordering is a property of the type. Ownership alone was still not enough, because the guard returned as soon as the direct child was reaped and the caller closes the pipes the moment it returns, so a grandchild mid-cleanup could still be cut off. It waits for the group to drain. 20 of 20 under nproc x 2 saturation, against 2 failures in 12 for the intermediate version. ## The resolve line was silent for the whole ninety seconds The same apply spent 90 seconds showing resolve and nothing else, then printed a 40-line trace whose actionable line was fifth from the top. That line had been on the wire since roughly second five. The evaluator already streamed both its phase and Nix's live stderr. ResolvePhase's doc comment says it exists "so the client can render progress instead of one opaque pause", and EvalFailed keeps a second copy of the stderr tail specifically because a caller "whose renderer discarded the live stream" would otherwise see only an exit code. The renderer discarded the live stream. Both are now rendered, along with the source upload's byte counter, which was also being thrown away. ## The progress writer could smear across the terminal Resizing the window during an apply left one ghost row per width change. The writer moved to column 0 and cleared downward, which is an in-place redraw only while the cursor is still on the row the line was drawn on; a reflow moves that row, so the clear lands elsewhere and the old text becomes scrollback. ix apply now draws through the same transport ui/tree uses, which reaches rows above the cursor by arithmetic and needs no cursor-position query. Two candidates were measured and rejected. Ratatui's inline viewport does not ghost, but it emits ESC[2J on a horizontal shrink and its cursor query goes to stdout while the backend writes stderr, so ix apply > log produced no progress output at all. A test built on vt100 or termwiz would have been useless here: both resize by truncating rather than rewrapping, and the broken writer passes under them. Two smaller defects went with it. Line widths were counted in characters rather than columns, so one CJK character or emoji in a VM name would produce the same smear with no resize involved. And below 15 columns the label and spinner were emitted at full width into a narrower terminal. ## What a stalled transfer looks like A transfer that stops moving is not silent. A dead github: download emits thousands of progress events, tenths of a second apart, all reporting the same byte count. The rate now shows 0 B/s rather than disappearing, because an absent rate renders identically to the first tick of a healthy transfer, and the line says no data for 41s once that has persisted, which is the one fact it cannot otherwise express. The threshold is five seconds, calibrated against a single cold nixpkgs fetch where the rate sat at zero for about four and a half. A slower afternoon will show no data for 6s mid-transfer with nothing wrong. ## Still open Nix's own fetch bytes do not reach the CLI yet, so a cold github: input is narrated in words rather than bytes. That is ix#9299, which parses Nix's structured activity stream on the node agent. Until it lands, the no-total byte display is code with a test and no producer.

a 6.7 MB Rust symbol name filled the fleet ClickHouse and stopped every log query

Fri, 31 Jul 2026 01:00:00 GMT

a 6.7 MB Rust symbol name filled the fleet ClickHouse and stopped every log query. For several hours on 2026-07-30 the fleet ClickHouse on hil-compute-2 refused every log and metric query with code 241 MEMORY_LIMIT_EXCEEDED, while the host it runs on had 263 GiB of 503 GiB free. Nothing in the fleet was unhealthy. The instrument that watches the fleet was full. profiles.function_samples was holding 92.08 GiB of primary index resident in memory to index 2.16 GiB of data on disk, which is 94% of that server's entire 98.32 GiB budget. ## why one table's index outgrew the server function is a plain String holding demangled Rust symbols, and it was part of that table's primary key. ClickHouse keeps the primary index of every active part in RAM for as long as the part is active, storing each mark's full key, so every one of those symbols was resident. Rust writes the whole generic type into a symbol name, and a tracing_subscriber layer stack nests: each .with(...) wraps the entire previous type inside a new one, so the name grows by nesting rather than by adding. Measured across a 2,000,000-row sample of the live table: | function length | bytes | | --- | --- | | median | 28 | | p99 | 286 | | mean | 2,113 | | max | 6,712,193 | A mean 75x above the median is the signature of a few enormous values rather than broad growth. Adaptive granularity then compounded it: a mark ends after 8192 rows or 10 MiB of data, whichever comes first, so multi-megabyte rows produced a mark every few rows instead of every 8192, and each mark stored its full key. The rows most expensive to index were indexed most often. The comparison across tables is the argument. otel.otel_traces holds 3.51 TiB and 67.13 billion rows, 1,600x more data, and indexes it in 52.68 MiB. ## the part worth carrying away: the fix had already merged This exact fault was diagnosed and fixed 20 hours before it recurred. Commit aab17057e1 added PRIMARY KEY (service, profile_type, timestamp) to profiles-schema.sql, and its message quotes the same 19.86 GiB part and the same 48x inversion. It merged to main. It deployed: the generated config on the host carried the new line. It could never take effect. The statement is CREATE TABLE IF NOT EXISTS, the table existed, so the whole thing was skipped, and ClickHouse has no ALTER that changes a primary key. A correct, merged, deployed fix sat inert while the fault it fixed grew back worse, from 89.14 GiB over 84 parts to 92.08 GiB over 213. Nothing anywhere compared the schema a host declares against the table the host actually has. A drift gate that closes that gap is in progress. ## what changed The table was rebuilt so the committed key takes effect, keeping all 81.28 million rows. The order was swap-first: an empty fixed table was exchanged into the live name so inserts landed in it immediately, then the history was copied out of the old table, which by then had no writer. Copying a partition at a time failed on a single 6.59 GiB allocation, because opening a part loads that part's index and these were the pathological ones. One part at a time, unloading between each, held memory flat at about 10 GiB for all 638 parts. | | before | after | | --- | --- | --- | | resident primary index | 92.08 GiB | 830.53 KiB | | index as a share of the data it indexes | 4,262% | 0.06% | | MemoryTracking | 97.29 GiB | 8.66 GiB | Row counts could not verify that copy, and checking them is how a lossy one would have passed: SummingMergeTree collapses rows sharing a sorting key, so the new table holds 249,847 fewer rows than the old and is still complete. The measure columns are the invariant, since summing is associative, and all four came across whole plus the profiler's live writes during the copy. ix#9285 caps the demangled name at the producer, 1 KiB, which is 3.5x the measured p99. Truncation appends a stable digest of the full name rather than just cutting, because a plain prefix would collapse two different generic monsters into one string and SummingMergeTree would then silently inflate one row's counts with another's. ## what is still open The profiler is still emitting multi-megabyte names until ix#9285 lands; they no longer reach the resident index, but they still cost disk and merge time. LimitNOFILE=262144 on the ClickHouse unit was pinned during recovery and is currently raised only on the running process (ENG-11573). And system.metric_log is disabled on the fleet's own observability store, so none of the accumulation curve behind this incident can be reconstructed (ENG-11574).

index is tracked inside ix, not vendored as a submodule

Fri, 31 Jul 2026 00:30:00 GMT

index is tracked inside ix, not vendored as a submodule. ix consumed index as a git submodule at ./index. It no longer does: index's tree and all 3,703 of its commits were rewritten under index/ with git filter-repo --to-subdirectory-filter and merged into ix, so index/ is ordinary tracked files and git log -- index/ returns that file's real history rather than one import commit. Clone plainly. --recurse-submodules and git submodule update --init --recursive do nothing now, and a fresh worktree no longer needs a second step before it can build. There is nothing left to bump. ix's flake still reads index.url = "path:./index", but a relative path input to a tracked subdirectory locks as {"path": "./index", "type": "path"} — no rev, no narHash. The gitlink and flake.lock could disagree about which index a commit meant; that state can no longer be expressed, so the guard that policed it, its fixture suite, its repair bot and its required check are all gone. Three cargo git dependencies became path dependencies. astlog-core, ix-vt and audio-dsp were fetched from github.com/indexable-inc/index over the network at pinned revs. They now resolve to index/packages/... in the checkout, which also removes their fixed-output fetch hashes — and with them a recurring hazard where a store path pasted into an index doc page poisoned the fetch and failed eval for every workflow that touched the flake. The public indexable-inc/index continues to exist; it becomes a read-only projection of index/ rather than the place the work happens.

nix-dev-build: editing the nix fork without rebuilding the closure

Thu, 30 Jul 2026 03:50:00 GMT

nix-dev-build: editing the nix fork without rebuilding the closure. Four sessions in one night iterated on the nix evaluator's C++ through a whole-package nix build, which recompiles the modular C++ closure in a sandbox for every one-line edit. The tree is a meson project and the fork's own manual documents the ninja loop, so that work was avoidable the whole time. nix run .#nix-dev-build -- --checkout is that loop as one command. It finds the checkout, configures meson if the build directory is absent, runs ninja, and names the binary it produced. Two independent runs on the same 18 core aarch64-darwin Mac, each phase timed alone with the dev shell entry outside the span. Entry is 0.4 to 0.9s per invocation on top. | step | run A, load 13 to 24 | run B, load 7 to 10 | | --- | --- | --- | | meson setup | 12s | 11.9s | | first full build, 332 targets | 93s | 51.3s | | rebuild after touching one file | 18s, void, see below | 7.1 to 8.9s | | no-op rebuild | 1s | 0.1s | Both runs are real. The one-file row is the one to be careful with, and it took three sessions and a disagreement to pin down, because two different effects were being confused for one. Which file you touch sets the cost. At a load held between 7 and 8: 7.9s, 7.2s and 7.1s over three runs touching src/libexpr/eval.cc, 8.9s on primops.cc, 2.1s on nixexpr.cc. A 4x spread with load constant, so a single figure needs its file named or it reads as a promise about somebody else's file. Call it 2 to 9s for a body edit in libexpr. Run B recorded its file; run A did not. The rebuild is serial, and contention doubles it, but load average will not tell you which you got. The rebuild needs exactly one core, so a jobs flag earns nothing on a single-file edit: ninja -j1 costs 7.03s and 7.34s against 6.36 to 6.80s at the default. Thirteen timings of the same eval.cc edit across an evening on a shared machine by two sessions, sorted by real over user: | real / user | real | reported 1 minute load | | --- | --- | --- | | 1.04 to 1.12, nine runs | 6.36 to 9.38s | 13.18 to 45.37 | | 1.49 to 1.62, four runs | 12.33 to 15.78s | 24.90 to 37.21 | The ratio separates fast from slow exactly. Load average does not, and the two ranges overlap almost completely: the fastest run of the night sat at a reported load of 39.24, a 15.78s run sat at 24.90, and three runs at a reported load of 42 to 45 came in at 6.77 to 7.55s. That is the instrument, not the machine. Load average is a decaying one minute mean and this rebuild is a seven second event, so it reports the minute that just ended and stays inflated for a minute after a burst of other work has finished. So report real and user together rather than load. And discard the first run only after an idle gap, which is narrower than the blanket rule an earlier revision of this entry gave: the 34% penalty, 9.06s against 6.77s steady, was measured on a first run after a gap, while three consecutive runs taken immediately after building showed no penalty at all, and a third set taken while building intermittently showed 10%. This entry twice claimed something stronger and both claims are withdrawn. First that the one-file spread was file size and not load, then that load explained it with a threshold at the core count. The file spread is real, measured back to back at constant conditions. The contention effect is real, and real over user is its signal. Reported load average predicts neither, which is why run A's rebuild row above is marked void rather than reinterpreted: it was taken above the load gate its own author was enforcing, its file was eval.cc like everyone else's, and no user time was recorded, so nothing in it can be classified. user inflates when contended too, 6.10s to 9.76s, so the same compile costs more processor time and not only more wall clock. Why is open, and the two obvious candidates turn out not to be independent on this part. hw.nperflevels is 2: perflevel0 is 6 cores named Super with 128K L1d and 16M L2, perflevel1 is 12 named Performance with 64K L1d and 8M L2, and there is no efficiency tier at all. A compile displaced to the lower tier therefore loses half its L1d and half its L2 as a consequence of moving, so displacement and cache pressure are the same explanation rather than competing ones. They separate only for the narrower case where the compile stays on Super and other processes evict its lines. Nothing here measures that the cache delta causes the 1.59x. Forcing the lowest tier with taskpolicy -b costs 2.5x in user, which is an upper bound rather than a measurement, because that flag drops scheduling priority as well as tier. Isolating it means pinning to perflevel0 specifically, not changing quality of service, under contention, on a machine somebody has claimed. A body-only edit runs 3 of 10 edges and does not relink src/nix/nix at all, because the dylib symbol file is unchanged and the edit arrives through dynamic linking. The dependencies are not vendored here. Every run re-execs itself under nix develop #default, so the compiler, meson, ninja and the libraries nix links against come from the checkout's own flake, and entering it costs 0.41s warm. The flake reference is a bare path rather than path:, which matters more than it looks: a path: reference copies the whole directory into the store on every invocation, and in a checkout that has been built once that directory contains a 2.0G build/. A bare path resolves to git+file://, so .gitignore applies and the store copy is 17M. Anything scripting this loop by hand hits a trap the manual does not mention. configurePhase and buildPhase are stdenv shell functions, and under nix develop --command bash -c they are not defined: type -t prints nothing for both and the run dies with configurePhase: command not found. Drive meson setup and ninja directly instead, which is what this tool and packages/nix-ninja-build both do. ## Which binary you built, and why --version will not tell you The report always names the absolute path, the checkout's revision, and the nix already on PATH: The version strings are the point. Meson takes the version from .version, so a checkout build of any branch prints a bare nix (Nix) 2.34.7, while the packaged nix-ix stamps its revision in. The build is therefore the one that looks stock, which is the opposite of the intuition, and a test like "does --version contain +ix" identifies the system nix rather than yours. Two builds of two different branches are indistinguishable by version string altogether. So the path and the revision are the identification, and both binaries are printed side by side so the difference cannot be misread. The revision is reported rather than compiled in on purpose. nix-ninja-build writes the version into .version in its scratch copy, which is the right answer there; doing it to a developer's checkout would modify a tracked file in their working tree. ## What it refuses, and what it does not do There is no fallback to nix build. A ninja failure means the tree does not compile. A checkout that is not a nix source tree is refused, naming each marker it looked for and whether it was found. A build directory configured against a different checkout, or left broken by a failed configure, is refused rather than built through, since ninja's output in that case is confusing rather than wrong. packages/nix-ninja-build remains the other incremental lane and is not replaced. It materializes the packaged source into a scratch directory and turns each compilation unit into its own content-addressed derivation, on x86_64-linux only. This one builds the checkout you are editing, with local ninja, and is the only lane that works on aarch64-darwin. ## The ccache advice in the fork manual does not hold on this tree The manual says to use ccacheStdenv to "drastically improve rebuild time", and --shell native-ccacheStdenv reaches it. On this tree it very nearly does nothing, and the obvious check for why is the wrong one: ccache is not on PATH in either shell, so its absence proves nothing either way. The compiler is the tell, and it does route through ccache, clang++ resolving to ccache-links-wrapper-4.12.1 against clang-wrapper-21.1.7 in the default shell. ccache then declines almost every call. A full 332 target build through that shell recorded 17 cacheable calls out of 330, 5.15%, all misses on a cold cache, with 284 of the 313 uncacheable ones reported as Could not use precompiled header. The tree compiles with a precompiled header, and ccache will not cache such a compilation unless sloppiness includes pch_defines,time_macros. Setting that, or dropping the precompiled header, is what would make the advice true. Neither is done here. That also means the 34.3s first build measured through the ccache shell is not a caching win. The cache was cold with zero hits; the difference from 51.3s is machine load, 7 against 10 rising to 95. Stated plainly: the tool has only been run on aarch64-darwin. The Linux side is covered by the packaged build and the repo's checks, not by execution. A prompt rule pointing future sessions at this tool is proposed separately and is waiting on a human read, since it changes what every session follows.

the flake bump commit now names every input it moved, evaluator pin included

Thu, 30 Jul 2026 03:30:00 GMT

the flake bump commit now names every input it moved, evaluator pin included. ix's automated relock moved more than its commit message admitted. Three real examples, all authored by github-actions[bot], all with a subject naming only the submodule: index/nix-src is indexable-inc/nix, the evaluator every host in the fleet is built with. It advanced on its own, inside a commit whose message did not mention it, and then deployed. The reusable update-flake-lock.yml now renders the commit message and the pull request body from the lock itself, so the same commit would have read: This is reporting only. Which inputs move, when they move, and what gets deployed are all unchanged. ## the input is two levels down, which decides the whole design nix-src is not one of ix's root inputs. It is an input of the index flake, so ix inherits it, and relocking the index gitlink drags it along. A report restricted to a lock's root inputs, which is what the neighbouring escalation watcher does deliberately to keep its alerts short, names nothing at all for these three commits. So inputs are named by their path from the root, index/nix-src rather than nix-src, walked breadth first over the lock graph. Keying on the lock's own node names would have been the easier read and is wrong twice over: nixpkgs_2 style suffixes renumber whenever the graph changes, which reports a renumbering as a move, and a genuine move hides behind the rename. Diffing the lock as text is wrong the same way, in the other direction: a reformat claims every input moved. ## an empty report is a sentence, not an empty section A bump that moves a gitlink whose lock node already records the new revision moves no input at all. That case prints because a report whose quiet state is an absence is satisfied by a report that is simply broken. packages/submodule-sync-test pins both halves against the real workflow step: one case asserts the message lists exactly the moves that happened, one line each, and one drives the no-move path and asserts the sentence. Deleting the report from the step fails the first with listed: []; making the reporter fall silent on zero moves fails the second. Both were watched failing before either was trusted.

Agent memory moves into the repo: .memories/ files, ranked BM25 recall, nothing injected unasked

Thu, 30 Jul 2026 03:20:00 GMT

Agent memory moves into the repo: .memories/ files, ranked BM25 recall, nothing injected unasked. Every repo can now carry a .memories/ directory: one fact per markdown file, YAML frontmatter, found by reading the directory. Memories.search("query") in the kernel returns them ranked, alongside the directories it actually read. The prompt rule this replaces had been pointing at a subsystem that was switched off. It told every session to maintain a MEMORY.md index inside a directory CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 had disabled, so the instruction named a path the harness no longer loads while the real protocol arrived separately through a digest. Three things are derived rather than stored, because every hand-maintained index in this setup was wrong when checked and each was correct when written: MEMORY.md listed a file that does not exist, ix/docs/index.md routed changes through a worker deleted seventeen days earlier, and the prompt rule above. The two systems that never broke, lib/skills.nix and agent-context, are the two that derive from the filesystem. So weight comes from the validation log rather than a number somebody typed. Only validated: [{at, by, how, ok}] is written after birth, and how is the load-bearing field: a claim nobody can re-run is a date with a sentence attached. A failed re-check is recorded as ok: false rather than dropped, so the next reader learns the thing stopped being true instead of paying the cost again. Staleness comes from based_on: [{path, blake3}] compared at read time, which is basis_changed from the weave prelude applied to files: Nix derivation-input semantics, so no crawler and no TTL. And the reverse of related: is computed on read, so it cannot drift. There is no index on disk. file_search::EphemeralSearch builds one in RAM per query, 52ms over 228 documents, which deletes the class of bug where a stale index answers a question about a changed file. This release extends file-search with a multi-field ephemeral index so tldr and handle can be boosted honestly instead of by repeating text, which would inflate document length and discount every other term. Nothing is injected at session start. That is measured rather than preferred. A 2026-06-12 study on this fleet (14 agents, live A/B) found deliberate prior-search paying four to eight times over: 53k injected tokens against 220-400k tokens of avoided rediscovery across ten recurring task types. Ambient injection into ordinary prompts was net-negative in the same study, with three of five casual prompts pulling 0.3-9k tokens of noise, breaking even only when score-gated at 0.70 with a token cap. So memories reach a model exactly one way, by being searched for. memory-secret is the one lint rule with an incident behind it. A live lin_api_* key once reached over two hundred indexed chunks here, and validated.how holds a command line, which is exactly that shape, except a memory is committed on purpose. It reuses the redaction table at packages/source/meta/src/sanitize.rs rather than a second copy. The 150-file directory budget, by contrast, is not evidenced, and CONTRACT.md says so: the only study on this fleet is silent on corpus size. It stays as a forcing function for consolidation, not as a measurement. The companion change converts 228 ix/docs pages into the same format, so one search covers reference pages and situational notes alike, and removes the playbook docs renderer. docs/ keeps only raw artifacts: vendor datasheets and profiling figures. One result worth reporting because it is the weak half. A query made of exact tokens is decisive: ipmitool sol activate host hang returns its page at 34.76 against 12.40 for the runner-up. A prose query over the converted docs is not: three near-ties, two of them false matches where "collection" stems to "collect". Hand-written tldr fields do much better than converted ones, which suggests a corpus property rather than a ranking defect, and it names the condition under which an embeddings lane would earn its keep.

A default.ix can declare VM templates and pin instances of them

Wed, 29 Jul 2026 21:10:00 GMT

A default.ix can declare VM templates and pin instances of them. A default.ix can now export templates, each one a function from params to what index.lib.mkVm returns, plus an instances block that pins instances of them in the repo. index.lib.templates.renderConfig renders every declared instance through its template and merges the result with the config's named VMs, so a plain ix apply creates them and cannot tell which VM came from where. worker@1 is the instance name, systemd's spelling; worker-1 is the VM. They differ because they must: @ is not legal in a networking.hostName and introduces a digest in an OCI reference. The node name is derived once and injected as the name param, so a template body is index.lib.mkVm({ name, ... }) and one that names its VM anything else is refused with the reason. Params are unchecked at the boundary in this version — nix still refuses an unexpected param by name, and the module system types everything a param reaches. The JSON Schema generator that ix new worker --help will render from shipped in index#4450, but it reaches a template's params only when they are one named parameter rather than a destructured one; RFC 0042's Typed params section records that gap and index#4451 covers deep checking. The imperative half of RFC 0042 (ix new, a server-side instance record, and apply re-rendering recorded instances) is not built; a config exporting neither key evaluates exactly as it did before.

a .ix module's type annotations now generate a JSON Schema

Wed, 29 Jul 2026 19:00:00 GMT

a .ix module's type annotations now generate a JSON Schema. The ix2nix-wasm plugin has a second export. builtins.wasm { function = "schema"; } takes .ix source and returns a JSON Schema (draft 2020-12) for the module's parameters, generated from the same TypeScript annotations that already lower to eval-time __ixTy checks. The ix2nix binary grew a --schema flag over the same code path. ## why a checker could not answer this packages/ix2nix/src/ty.rs used to walk an annotation straight onto a __ixTy. expression and drop the type. A checker is a Nix function, so nothing downstream could ask a type what it accepts. That single missing property is what blocked three separate things at once: a JSON Schema for params.json completion, ix new

ix

index is no longer a submodule: one repo, and nothing left to bump

A cancelled apply used to brick the regional evaluator, and the resolve line never said so

a 6.7 MB Rust symbol name filled the fleet ClickHouse and stopped every log query

index is tracked inside ix, not vendored as a submodule

nix-dev-build: editing the nix fork without rebuilding the closure

the flake bump commit now names every input it moved, evaluator pin included

Agent memory moves into the repo: .memories/ files, ranked BM25 recall, nothing injected unasked

A default.ix can declare VM templates and pin instances of them

a .ix module's type annotations now generate a JSON Schema

the CVE ratchet stops running on pull requests

nix-debugger skill: find what actually caused the rebuild

code review moves to Gerrit, because jj and Gerrit agree about what a review is

we removed CVE scanning, which had not scanned anything since 10 July

channels were loaded but muted; the managed layer now says yes

A running command's output no longer jumps sideways when it finishes

House prompt: define acronyms, derive instead of copy, verify in a second agent

PR descriptions now distinguish Linear's closing verbs from Refs

Every Rust binary now carries a GNU build-id, and the build refuses one that does not

lazy trees is off again: its own mutation fix costs hydra 13x the kernel time

claude subcommands work again: the wrapper stops prepending flags ahead of them

an example the aggregator cannot call now says which argument it choked on

tree-sync: pushing a source tree no longer deletes files at the wrong depth

a 23 MB Rust binary was dragging 2.5 GiB of build inputs behind it

A malformed .svx frontmatter now fails lint instead of main

A complexity ratchet, with thresholds measured instead of quoted

A primary checkout is now read-only to agents, not just uneditable

nox self-build crosses five repaired boundaries

The fleet's log store answers operator machines, and a refusal stops reading as a wrong password

two of three subagents move to the Elixir kernel

a CI cache entry that wanted to be a derivation

the Claude Code updater now regenerates everything a version bump invalidates

what a broken cache lane was hiding

the Claude Code env extractor no longer pins the minifier's helper name

every build in CI was compiling single-threaded

a dirty ix checkout broke home-manager switch outright

cache-push runs ten shards, because the dispatcher now sizes them small

every Elixir package moves to 1.20 on OTP 29, and hex gets the darwin sandbox allowance that made it possible

two mcp-ex tests blamed weave for four days; the fixture's shebang was unrunnable in the sandbox

bare cargo could not run in index at all, because ix's config leaks in

Claude Code bumps to 2.1.220

git stops writing a commit-graph on every fetch

import ctypes works again on macOS 27

Every VM now ships the tools people actually reach for first

the BEAM toolchain tables name beamPackages only, because a deprecation warning is a build failure here

a failed cache-push root now prints its builder log, and ix-site builds again

two clippy gates were red on main, and the log tail hid why

the .ix converter goes back to IFD, and the committed copy is gone

the version tables only advertise versions that still build, after a sweep of every nixpkgs alias this repo names

a dangling site link now fails lint by filename, and the Check gate always did build the site

the submodule-sync test moves to Rust, and the shell fence goes green

The hosted-mac cache lane is gone; darwin consumers pin cache-ready again

the prompt reads jj state in a jj workspace instead of the exported git view

POC: Gherkin (cucumber-rs) specs audited with cargo-mutants

nix-cargo-unit: unit names now hash build-script-run deps (collision fix)

Agents use the Elixir kernel and keep a native shell

Key-blind agent sandboxing is a reusable module

.ix modules accept TypeScript type annotations, lowered to runtime checks

main lint gate green again after quoting a legacyPackages splice

Package names are IFD-free again: example fan-outs move to legacyPackages

CI budget kills now announce themselves in the log, the annotations, and the mirror results

mkapp scaffolds ship the real shadcn-svelte registry, themed from the ghostty palettes

Agent memory grows an entity graph: about edges, minted ids, graph-walking recall

the .ix converter is committed, so imports realize nothing mid-eval

kernel module autoloading works in guests, nftables firewall starts green

scaffolded flakes eval again, and index.lib.importIxWasm ends the deep-path era

Jason works in kernel exec cells

mkapp + Serve.app, check-gated hot reload for AI-built web apps

Child-agent spawns name a missing working directory instead of dying as exit 2

cargo-unit plans against a manifest-scoped stub, so a source edit no longer re-resolves the workspace

each bundled mcp module's Nix definition now lives next to its Python source

Rev-pinned builtins.fetchGit inputs evaluate without network once cached

Fork patches are now jj megamerge commit DAGs

js-nix: write Nix in JavaScript syntax, compiled at eval time by builtins.wasm

The kernel grew an agent coordination bus: issue feed, atomic pickup, session messaging, Requests

Kernel commands name a missing working directory instead of failing as exit 2

Codex now follows the current MCP generation

Kernel commands no longer follow the movable OS cwd

the stock-Nix parse gate is sharded per top-level directory

editing one mcp module no longer reruns all ~60 bundled test derivations