A dev round refreshes what the edit touched

A graphitron:dev round costs work proportional to what the developer changed, on the store side as the classpath census now does on the read side. Today a round re-reads nothing it does not need to (R916), and then rewrites and re-derives almost everything regardless: it re-parses every schema document, deletes and rewrites the whole of its graph’s partition, and re-evaluates every registered materialization for that graph, whether the round fired because a .graphqls file was saved, because one consumer class was recompiled, or because a dev session started over a store that was already current. When this lands, a save re-parses the documents that moved, rewrites the partitions those documents own, and re-derives the registrations whose inputs those partitions feed; a round that changed nothing derives nothing.

Partition here is the store’s word: the rows one graph, or one classpath or schema source, owns in a relation that several of them share. A registration is one entry in the materialization register, a stored view whose rows are maintained in a table so readers do not pay the view’s own cost; refreshing one means deleting its target’s rows for a graph and re-running the view to refill them.

Four unconditional passes, and only the first has been addressed.

Passes 2 to 4 run on both watch cadences. A .class-only recompile re-parses and rewrites every schema fact although no schema byte moved; a one-file .graphqls save does the same for every document except the one that changed.

The costs are not comparable to each other and should not be added up. Pass 4 is the expensive one by orders of magnitude: a real consumer capture was measured from inside the refresh at 15477.1 seconds over twenty registrations, and even a settled store’s price list put fourteen positions at 199 seconds. Passes 2 and 3 are unmeasured here, and measuring them is part of this item; what makes them belong in it is not their present size but that they are what pass 4’s saving is gated on. A capture that has just deleted and rewritten its graph’s whole partition has falsified every claim that partition backs, so it must re-derive everything, correctly. Refreshing less is only reachable through rewriting less.

DevMojo.execute runs the initial generator pass, whose capture already refills every registered materialization for the graph it captured, and then calls Materializations.refreshAll on the session store. refreshAll refills every registration for every graph the store holds, unconditionally. On the ordinary case, one graph and an initial run that was not skipped, that is the entire register evaluated a second time to produce the rows the first pass just wrote.

A graphitron:dev start over a store that already holds the graphs it opens stops re-deriving the materialization register at all. The language server and MCP ports bind one full register pass sooner, plus one further pass per graph the store holds whose partitions no capture has disturbed. Every round after it re-derives the registrations whose inputs its own edit falsified, which on a .class recompile or a one-document save is a small fraction of twenty. Nothing about generated output changes, on any of the three.

What a reader may observe is worth stating exactly rather than sweepingly, because the first draft of this item promised more than it could deliver and four review rounds said so. Within one JVM, which is every cadence a build or a dev session produces on its own, no reader observes a stale row: a partition is refilled unless something recorded that it was already filled from rows nothing has touched since. Two cases fall outside that, both of them named and argued under "What the rule gives up" below rather than left to be discovered: a target somebody emptied by hand, and two JVMs capturing into one shared store at the same moment.

That single-JVM promise is one the rule keeps only over a store whose source-keyed relations are actually partitioned by source, and four of them are not today. That is a defect in the warm-refresh path rather than in this rule, it is filed as R872, and this item depends on it; the premise section below states the dependency and says why it is a dependency rather than a fourth thing given up.

-Dgraphitron.dev.skipInitial gets the same win and no more, which is worth saying because an earlier draft advertised it as a case of its own. That flag skips the emitting run, not the capture: buildOutputQuietly reaches buildOutput, which is a projection of the one pipeline and captures like any other, so such a start refreshes its own graph once and then pays refreshAll on top, exactly as an ordinary start does. It stopped being the extreme case when R859 collapsed the double capture; before that it was the one start paying one capture rather than two.

The narrow fix is a condition at the call site: skip the refresh when a capture in this session has already refreshed this graph. Reject that shape, for four reasons, and put the currency question in the store instead.

First, the mojo cannot answer it. Capture demotes to a private in-memory store in two cases, an unopenable cache (FactCapture logs DEMOTED_TO_MEMORY) and a graph name already recorded against another base directory (FactCapture.ownsGraph), and neither is reported back through GraphQLRewriteGenerator to the mojo.

Second, it answers only for one graph. The store’s other graphs are the larger half of the cost, and the mojo knows nothing about them; a condition that skips its own graph and refreshes the rest is refreshAll gaining an exclusion parameter, which is session knowledge pushed into the store’s API by another door.

Third, the knowledge outlives the process. A graph’s partition is filled by whichever module’s build captured it, in another JVM, possibly days ago. The only place a fact about it can be recorded so that this session can read it is the store, which is where every other fact about a capture already lives.

Fourth, the shape. A refreshAll that is safe to call and ruinous to call twice invites this bug at the next caller, and today’s caller is its only production caller. The fix that removes the trap is the one that makes the cheap answer the default answer.

This is the project’s standing move rather than a new one: decide once and record the decision as a fact, then let the reader ask instead of assume. Two relations about the materializer already work that way, meta_materialize for the registrations and meta_materialize_dependency for the refresh order derived from the stored view definitions. Both sit in meta_, because both are a function of the DDL alone; what this item records is a function of what a run did, which is why it lands in store_ instead, and the Implementation section quotes the family comment that draws that line.

The cheapest alternative of all, deleting the call and trusting that every capture refreshed what it wrote, is rejected on the same grounds and one more. A cold store, and a store holding a graph no capture ever reached, genuinely need the pass, so the call cannot go; and with it gone the argument that the targets are current would live only in prose, which is the state this item is a report of.

What the rule gives up. Three properties, and all three are traded knowingly. Today’s unconditional pass silently holds each of them, so each is a real loss rather than an oversight. A fourth candidate was raised in review and is deliberately not here: the four source-keyed relations the warm refresh empties wholesale, which the premise section takes as a dependency on R872 and argues there rather than accepting as a trade.

A hand-damaged target stops being repaired by a restart. Somebody who empties a target through the store console the dev session exposes, or otherwise, no longer gets it back on the next start, because the claim recorded for it still stands. That is the ordinary standing of a cache whose contents were hand-damaged, and the remedy is the ordinary one: delete the store directory and let the next build refill it.

A re-walk that changed nothing still invalidates. The rule below records that a partition was filled and deletes that record when anything the partition reads is rewritten, without asking whether the rewrite changed a row. So a sibling graph in a shared store refills after any capture that re-walks a source it names, even where the rows came back byte-identical. This is the price of recording a claim rather than a content stamp, and the store cannot currently be made to pay less: store_source.stamp is NULL by design for exactly the two kinds that hold these rows, jOOQ schema packages and directory roots, and last_seen moves on every run that merely names a source. It is also strictly less work than today, which refills that partition unconditionally whether or not any capture ran at all.

Two JVMs capturing into one store at the same moment can leave a claim that should have been deleted. The reader-side pass refills a partition and records its claim in one small transaction, but it does not serialize against a capture in another process. A foreign capture that deletes this graph’s claims before the pass inserts one, and commits its rewrite after the pass has read the rows, leaves a claim recorded against rows that have since changed, and unlike every case above the wrong answer then persists instead of being recomputed on the next start. It needs two JVMs sharing one store simultaneously, with one capturing a source the other’s graph names. Closing it wants cross-process serialization the store does not offer, and the obvious instrument, locking the graph’s source rows for the pass, invites a deadlock against a capture that locks the same hundreds of rows in its own order. If it is ever observed, the cheap detector is a watermark: read max(last_seen) over the graph’s sources before the pass and again before each claim, and withhold the claim if it moved. That reuses the column dismissed above, correctly, because a currency key may not err and a race detector may err toward doing more work. This item leaves it unbuilt rather than building a mechanism against a failure nobody has seen, and states the window here so that the promise in "What changes for a consumer" is one the rule actually keeps.

This section replaces the rule the first three review rounds refused, and the reason it was refused decides the shape of what replaces it. That rule recorded the graph’s last_captured stamp at fill time and refilled a partition when the stamp no longer matched. Currency, though, is a property of the rows a partition reads, and not all of those rows are graph-keyed: intent_spelled_table_live joins store_graph_source to sql_table, whose key is (source_name, table_schema, table_name), and jvm_class is (source_name, class_name). store_source’s own comment says why no stamp of a graph’s can speak for them, that it "can say what a file hashed to, never which graph read it". A capture of graph A re-walks a shared jOOQ package and rewrites those rows inside A’s transaction, while `FactCapture.writeGraph moves last_captured for A alone, so B’s stamp still equals the one its fill row recorded against rows that no longer exist.

So this draft stops comparing values. A partition’s currency is recorded as a claim, and every writer that falsifies a claim deletes it in the same transaction that falsifies it. That inverts where the argument has to hold, which is the whole gain. A stamp rule is sound only if the recorded value covers everything the partition reads, which is what three rounds could not establish and what round 3 established the store holds no material for. A claim is sound if every writer of what the partition reads deletes it, which is a statement about writers, and there are two kinds of them.

One relation, two columns. store_materialized_partition (source_view_name, graph_name): a row claims that this graph’s partition of this registration’s target holds exactly the rows its source view computes. No stamp column and no timestamp, deliberately, because a value nothing compares is a value nothing keeps correct; the row’s presence is the entire claim. The family placement changes with it. The first draft put this relation in meta_, which that family’s own comment forbids: "Not store_, because these rows are a statement of what this file declares, never a record of what a run read." A claim is precisely a record of what a run did, and `store_’s comment opens with "Every run of the generator leaves a record of itself here."

Who writes a claim. Only a refresh, and only for a partition it has just refilled. Materializations.refresh, the capture-cadence entry point, stays unconditional and records; the reader-side pass refills the pairs with no claim and records those. A writer never consults a claim: a writer that has just rewritten a partition’s inputs knows they changed, and only a reader has a question.

Who deletes one, and why that is only two writers.

Why membership is the right reach and not an approximation of one. The relation the invalidation reads to find the affected graphs is the same relation the affected views read to scope themselves. `store_graph’s comment states that rule: any derivation joining an SDL fact to a catalog or classpath fact "is underdetermined in a shared store until a membership relation says which sources are the joining graph’s; store_graph_source below is that relation", and "such a join scopes its catalog side through it". A registered view that obeys that rule sees exactly the source-keyed rows of the sources its graph names, which is exactly the set of graphs the upsert invalidates. Soundness is therefore not a second rule to keep beside the first; it is the first rule read from the other end. A view that disobeys it is already wrong, resolving a sibling module’s tables into its own answers, and the gate below is where that stops being prose.

What the hooks cost. One DELETE per upserted source, over a relation holding at most one row per registration per graph, against a capture that already pays a full unconditional refresh of its own graph. Nothing on the capture cadence gets measurably dearer, which matters because that cadence is the one R856 is about.

Four properties are what make the rule sound rather than merely plausible.

A missing claim means refill, and absence is always the safe direction. Three ways a claim can be absent, all of them ending in the conservative answer. A partition filled before a registration existed lives in a different store file, the directory being stamped with the DDL hash and generator version (GraphitronModelStore), so it is not merely unrecorded here but elsewhere. A graph minted outside any capture, which CompileFacts and OwnedGraphPartition both do by inserting a store_graph anchor row, has no claims and refills; round 1 flagged those two writers as a hole in the old family roster with a benign outcome, and under a claim there is nothing there to get wrong. And a scratch store with no store_graph row records nothing at all, the foreign key declining it, so it refills exactly as today.

Invalidation is per graph rather than per registration, and that is what keeps the dependency order honest. A source rewrite deletes all of a graph’s claims instead of working out which registrations read that source. Conservative in the cheap direction, over a relation of twenty rows per graph, and it forecloses a failure the per-registration alternative would have had: a dependent still claiming currency while the prerequisite its view reads is refilled underneath it.

Partial progress is safe. The reader-side pass holds no transaction over the whole pass, which it cannot anyway because analyse commits, but each refill and its claim share one small transaction, so a pass that dies leaves claims only for the partitions it finished and the next pass finishes the rest. Ordering holds in the safe direction too: the pass refills prerequisites first, so a death mid-pass leaves a prerequisite fresher than its dependent and never the reverse.

Both refresh shapes survive unchanged. A target with no graph_name in its shape has no partition to claim and is refreshed whole and unconditionally, as today. All twenty production targets are graph-keyed, so the register is covered; the whole-target arm has residents only in the scratch fixtures of MaterializationOrderTest, which is what keeps those cases passing untouched. Note what changed in this argument since the first draft: the keying of the target now decides only the refresh shape, as it always did, and no longer stands in for an argument about what the target’s view reads. That substitution was the finding.

Refreshing less is gated on rewriting less, so this half comes first in the causal order even though it comes second in the plan. A capture that deletes and rewrites its graph’s whole partition has falsified every claim over it and must re-derive the register in full; there is no rule that can excuse it, and none should try. The saving is reachable only by making the round’s rewrites as narrow as its reads now are.

The store already models the unit, and says so in its own comments. graphql_type_declaration is keyed (graph_name, type_name, source_name, source_line, source_column), and its comment states what the source column is there for: it "records who contributed what and indexes the incremental-refresh unit ('which types does this file touch')". graphitron_minted_type_site says the same thing from the macro side, that its site count "is the carrier multiplicity an incremental refresh refcounts the type by". So the grain this half needs was designed in, twice, and nothing reads it that way yet. What is missing is not a schema change but a writer that respects the grain.

Not every SDL relation is at that grain, and the difference decides the work. The declaration relations are per file and can be retained per file. The coordinate relations are not: graphql_type_coordinate and graphql_field_coordinate are graph-keyed with no source column, being what the merge of every declaration site produces, and `graphql_field_coordinate’s comment says it is "written from the declaration sites". A type extended in two files has one coordinate row and two declaration rows, so a document’s rewrite can change what its neighbours' declarations merge into. The honest shape is therefore not "skip the files that did not change" but two grains: rewrite the declaration rows of the documents whose stamp moved, then re-derive the merged relations for the types those documents touch, which is the query the declaration relation’s own comment names. Any draft of this half that treats the merged rows as retainable per file is wrong, and it is worth saying here because it is the mistake the phrase "incremental refresh" invites.

The currency signal is already recorded. The SDL walk stamps every schema file that resolves to a regular file, through ClasspathSources.noteRegularFile and commitStamps, precisely so that "a currency check can re-hash a cold graph’s files without building its module". StoreRefresh cannot use it: freshSources tests only the names the classpath census produced, and no schema path is a member of that set, which the method’s javadoc states outright as a property it relies on. So the material is written every round and read by nothing, and the change on this side is a second question asked of the same relation rather than a new fact to record.

The parse is the same shape one level up. SchemaLoader.parsePerSource already reads per source, which is what makes a per-source cache a small change rather than a redesign: hold the parsed document per source across rounds in the dev session, keyed by content hash, and re-parse the documents whose hash moved. The registry the pipeline needs is assembled from all of them either way, so what is saved is the parse and not the assembly, and how much that is worth is unmeasured. The population is the same one ClasspathCensus holds for classfiles and SourceWalker holds for .java declarations, so this is the third instance of one pattern rather than a new mechanism.

What this does to the claim rule: nothing, which is the point. The rule as specified says the capture-cadence entry point stays unconditional and records, on the ground that "a writer that has just rewritten a partition’s inputs knows they changed, and only a reader has a question". That ground is exactly what this half removes. A capture that rewrites two documents out of ninety is a writer for what it rewrote and a reader for everything else, and it has the reader’s question for the rest. The rule answers it without amendment: the capture deletes the claims of what it falsified, through the two hooks already specified (its own graph’s rows ahead of its pass, and ClasspathSources.upsert for every source it rewrites, which is where a rewritten schema document already announces itself), and then refills exactly the partitions left unclaimed. It still never consults a claim to decide what facts to write. Materializations.refresh and the reader-side pass converge on one claim-driven body with two callers, which is a simplification of the specified design rather than an addition to it.

The objection this must answer, and does. R865 dropped every declinable refresh path on R876’s ground that "a refresh worth skipping is a registration worth retiring", and a reviewer should hold this item to that. It survives, because declining and not-recomputing are different acts. A declinable refresh lets a caller trade currency for time on its own judgment, and leaves a reader unable to tell which it got; that is the shape R876 rejected and this item does not reintroduce, the claim being a fact in the store rather than a caller’s option. Skipping a partition whose inputs are provably untouched computes the identical rows by not computing them, and it is the same trade R916 already made for the census and the store already makes for the jvm_ partitions. The register’s size stays a live question and stays R876’s; nothing here is an argument for keeping an expensive registration.

Phasing, and what is measured before what is built. The reader-side claim mechanism is specified below, has five review rounds behind it, and stands on its own: it removes the duplicate pass, and it is what puts the currency question in the store where this half can then ask it. The rewriting half is second for that reason, and its own first task is measurement, which the four-pass list above does not have for passes 2 and 3. What a Spec for it owes: what a round pays today for the schema parse and for the graph-partition rewrite, on this repo and on a schema with enough documents for the question to be interesting, and what share of a register refresh a one-document edit would actually avoid once the merged relations are re-derived for the types that document touches. If the answer is that a one-document edit falsifies most registrations anyway, this half is not worth building and the measurement says so.

The premise is now a closure statement rather than a cadence one, which is the second half of what the review rounds asked for. Every base relation in the gate closure of a registered source view’s reads, the closure defined below, is covered by one of the two hooks. A relation is covered when it is graph-keyed and rewritten only inside a capture transaction of that graph, or when it is source-partitioned: rewritten one source at a time, inside a transaction that upserts that source’s store_source row. A closure member that is neither, or one written on a cadence no capture owns, serves stale rows under this rule and does so silently.

Source-keyed and source-partitioned are two different predicates in this tree, and the first draft of this premise used the wrong one. A source_name column says how a relation is keyed. What decides whether a capture of one graph leaves another graph’s rows alone is StoreRefresh.PARTITIONED, a hand-maintained Set<Table<?>> that wholesale() subtracts: a base relation outside it and carrying no graph_name is emptied for every source by clear’s predicate-free `deleteFrom(table).execute(), on every warm capture of any graph. Four source-keyed sql_ relations are outside it today, and two of those are in the closure of four of the twenty registrations: sql_node_metadata and sql_node_key_column, reached through intent_node_metadata_defect by intent_node_id_instruction_live, intent_input_field_filter_role_live, intent_mutation_payload_refusal_live and intent_mutation_payload_column_live. So the premise as first stated is false over the register as it stands.

The failure it admits is the persisting kind, which is what decides what this item does about it. A capture of graph A empties those two relations for B’s sources without upserting any of them, so nothing deletes B’s claims and B is served its previous, still-correct rows. Then let A and B share one source, which is the ordinary reason two graphs sit in one store: A’s upsert of the shared source deletes B’s claims, the reader-side pass refills B’s partitions from a store in which B’s other sources' node metadata is gone, and records a fresh claim over the result. That wrong answer stands until B is captured again.

Why this is a dependency and not a fourth thing given up. The omission is StoreRefresh’s, not this rule’s, and it is filed as R872, which this item’s `depends-on names. Two reasons for taking it as a dependency rather than absorbing it into "What the rule gives up". First, what it would cost to absorb: a gate that lets the four registrations pass has to exempt the two relations by name, which is a roster of exactly the shape rounds 2 and 3 refused twice, and it would sit beside a claim rule whose entire argument is that a source-keyed read needs no exemption because a writer retracts it. Second, what it would cost to fix. A minimal fix does exist and is why this looked cheap when the dependency was taken: CatalogFactCapture.clearSchemaSources already deletes all four of these relations per source, in the same loop body as the ones the list does name, so adding four constants to PARTITIONED would stop wholesale() emptying them and nothing else would have to move. And sql_node_metadata’s own table comment already claims the property the omission breaks, that the relation is "refreshed in the same clearing round by the same walk" as `sql_table and that "a family boundary here would cut one refresh unit in half".

R872 rejected that fix, and what this item now waits on is different in kind. Its argument is that the list is the defect rather than its contents: nothing derives PARTITIONED, nothing checks it, and membership is an unverified promise that a per-source delete exists somewhere else, which is exactly the promise these four relations show can be broken. So R872 removes the list instead of extending it, and it is four phases rather than one constant edit. Phase one is the whole of what this premise needs: it cascades the sql_, jvm_ and java_ webs from their roots, replaces the per-source statements with one delete per root, and deletes PARTITIONED and wholesale() outright, after which these four relations are carried with nothing naming them. A persisting wrong answer is still not a trade and still a bug to depend on; the change is that the dependency is on a phase of a larger item, not on a one-line patch.

The closure, defined once because every assertion below ranges over it: recursion that ends only at base relations that are no registration’s target, and passes through a registration target into that registration’s own source view. Starting from a registered source view, a read of an unregistered view recurses into that view’s definition, a read of a registration target recurses into the source view of that target’s registration, and a base relation that is no registration’s target ends the walk and joins the closure. The pass-through arm is load-bearing rather than a refinement: a registration target is a base table, and seventeen of the twenty registered views read at least one, so under a walk that stopped at every base table the targets would be the closure’s most common member class and the premise would have to answer for them. It has no answer to give, and rightly: a target has no writer with a cadence of its own to cover, its rows being whatever its own source view computed, so its currency delegates to that view’s closure. That is the same delegation the refresh already performs when it refills prerequisites ahead of dependents, and it is sound under this rule for the reason the per-graph invalidation property above states: a source rewrite deletes the prerequisite’s claims and the dependent’s together, and the pass refills prerequisites first, so a dependent is never recomputed over a target whose own inputs moved. With targets passed through, the premise needs no coverage arm for them, a target not being a closure member.

This walk is a third one, deliberately not the recursion MaterializeDependencies runs, and not describable as that recursion "stopped at base tables", which is what an earlier draft of this section called it. That walk stops at a registered target and emits an edge saying the target’s registration refreshes first; this one passes through the target and keeps going. Both are a handful of lines over the same public primitive, ViewReferences.relationsReadBy, which answers what one stored view definition reads, parsed out of the definition rather than scanned for textually; the gate computes its walk in the test.

Four assertions over that closure, and the first is the instrument four rounds asked for: one that fails on the class of registration that breaks the rule, rather than one that passes while the rule is unsound. It is new in this revision, and it exists because the three that preceded it could not fail on the four registrations above.

Where each assertion lives, and the one production change it wants. Assertions 2 to 4 range over the model schema alone and stay in MaterializeRegistryGateTest, in graphitron-model. Assertion 1 joins a fact about the model to a fact about capture, and StoreRefresh is in graphitron, which depends on graphitron-model and not the reverse, so the join can only land on the capture side. FactSchemaGateTest is the home: it already sits in StoreRefresh’s own package, already reaches `Materializations and MaterializeDependencies, and already walks foreign-key and key-column closures over the generated model, so this is a sibling of what that class does rather than a new kind of test. The closure it needs is the pass-through walk defined above, computed in the test over the same public ViewReferences.relationsReadBy primitive.

The one production change the gate wants is a visibility widening. StoreRefresh.wholesale() is private static, and a private member is unreachable from another class in the same package, so the gate as written cannot call it; it becomes package-private, with a javadoc sentence naming the gate as its second reader and saying why reading the method beats restating its exemption list. No behaviour changes and nothing is exposed beyond the package. The first draft of this item said the gate needed no production change; that was true of the three assertions it had, and it is not true of the one that works.

Rounds 2 and 3 objected to a roster twice, on the ground that sql_ and jvm_ sit on it as capture-written families while the rule was unsound over exactly those reads. That objection does not carry against assertion 4, and the reason is not that the roster improved. A source-partitioned read is covered rather than exempted: hook 2 invalidates it, so there is nothing for a gate to catch there. Whether a source-keyed read is source-partitioned is precisely assertion 1’s question, which is where the objection’s residue now lands rather than in the roster. What the roster is left holding is the narrow question a prefix genuinely answers, each of those families having exactly one writer.

The gate is not debt this item introduces. A registration reading an off-cadence family is already wrong on the build path, where nothing calls refreshAll at all and the target is therefore never filled from the rows written after the transaction; the dev session’s unconditional pass is the only thing that would have hidden it, and it hides it on one goal out of several. So the premise is one the register already depends on, stated and enforced here because this is where it becomes load-bearing.

Everything in this section is the first half, the claim mechanism and the reader-side pass. The second half has no implementation section yet on purpose: its first task is the measurement named at the end of "The other half" above, and specifying a per-document rewrite before that number exists would be the mistake this file’s own reviewer rounds kept catching. What it will touch is already identifiable, and naming it is not the same as specifying it: SdlFactCapture and the graph-scoped half of StoreRefresh.clear for the declaration grain, a re-derivation of the merged coordinate relations for the types a rewritten document touches, SchemaLoader.parsePerSource and its caller in GraphQLRewriteGenerator.runPipeline for the parse cache, and ClasspathSources.upsert, which is already the invalidation hook and would simply start being reached by a schema document that changed rather than by all of them.

graphitron-model.sql. New table store_materialized_partition (source_view_name, graph_name), primary key on both columns, foreign keys to meta_materialize (source_view_name) and to store_graph (graph_name). Its comment states what a row claims, names the two writers that delete one, and states in one sentence the premise above, since that is where a future registration’s author will meet it. Column comments per the schema’s own convention; the store_ prefix places it in the family census with no exemption row needed, and the generated schema reference picks it up from the comments. No secondary index: the relation holds one row per registration per graph, twenty times the graphs in the store, so both reads over it are cheaper as a scan than as an index descent, and the gate that demands an index or a stated reason applies to registered targets rather than to this.

The foreign key into meta_ needs no meta_family_bridge row. That roster covers normalization crossings and says so explicitly, that "a foreign key is already a declared, engine-checked join path" and carries no rule anything could fork.

Adding a table changes the DDL hash, so the first build after this lands opens a new store directory and captures cold once. The directory it stopped using no longer stays behind: R858 has shipped StoreReaper, which sweeps on open and retains the directory this run opened plus the two most recently used others, so the cold capture is the whole of the cost and it is the standing cost of any DDL edit here rather than anything this item introduces.

Materializations.refresh(DSLContext, String, RefreshProgress). Unchanged in effect, plus the claim: delete this graph’s rows ahead of the pass, and insert one per registration whose partition it filled. Both statements run on the caller’s DSLContext, which is how the claim comes to be published in the same commit as the rows it vouches for. A graph with no store_graph row records nothing, the foreign key declining it, which is the scratch-store case and correctly leaves the partition unclaimed.

Materializations.refreshAll(DSLContext, RefreshProgress). Keeps its name and its postcondition, every target current on return, and gains the claim check: read the graphs and the claims once, refill the pairs with no claim in the existing order (registrations outer, graphs inner, so the dependency order is untouched), insert each claim in the same small transaction as the refill it vouches for, and call analyse only if something was filled. Returns the number of partitions refilled, which is the test observable, on the precedent analyse set by returning a count rather than logging. Its javadoc states the premise it now rests on and the concurrency window named under "What the rule gives up".

Materializations.invalidate(DSLContext, String sourceName), new and public: deletes the claims of every graph naming that source, one statement over store_graph_source. It lives here rather than in the capture package because the relation is this class’s, and it is plain-name jOOQ like the rest of this class, for the reason stated there: this module’s hand-written half does not reference its own generated half.

ClasspathSources.upsert. One added call to that method. The javadoc sentence that already says "this run is about to (re)write the source’s partition" gains the consequence, so the site states why it is the invalidation’s home rather than leaving that argument only in this item.

RefreshProgress. One new sealed arm, Event.RegistrationSkipped(registration, position, total, graph), emitted where the reader-side pass declines to refill, and two counts on Event.PassFinished so the pass-boundary tier says what the pass decided rather than falling silent. This is not decoration. R855 exists because an anonymous pass is unreadable, and a pass that skips everything and reports nothing would reintroduce exactly that by a new route: a person watching a warm dev start would see the same two lines as a person watching a stuck one. The sealed interface names every switch site when the arm is added, which is its stated purpose, and the skip arm keeps the name-before-statement property trivially, there being no statement.

DevMojo.execute. No code change. The comment at the call site says the refresh is there because a warm store whose capture was skipped would otherwise serve stale rows; that stays true and becomes precise, so it gains a sentence saying the currency question is now answered in the store and what the call costs on the ordinary path.

StoreRefresh.wholesale(). One visibility widening, private static to package-private, so the gate’s first assertion reads the predicate that decides the clear instead of restating its exemption list. Its javadoc gains a sentence naming the gate as the second reader and saying that the list is the definition rather than a summary of one, which is why a copy would be wrong. No behaviour change, and the method stays inside its package.

Nothing else for the gate. The remaining reach is the pass-through walk the premise section defines, a recursion over ViewReferences.relationsReadBy from the views the register names, plus two INFORMATION_SCHEMA reads, all computed in the tests. Worth stating because the first draft of this spec proposed exposing a base-relation reach from MaterializeDependencies, and the public primitive that landed with the re-evaluation metric makes that unnecessary.

SeededStore.derive. Clears store_materialized_partition before refreshing. The fixture seeds rows directly, without a capture and without upserting a source, so it is precisely the writer the premise excludes; clearing the claims is that fixture stating its own irregularity in one line, and it keeps the production surface at one entry point rather than adding an unconditional variant for tests to reach for. Its javadoc says so, next to the sentence that already explains why the helper refreshes unconditionally.

The first half’s tests are below, unchanged. The second half owes one observable of its own, stated here so the shape is agreed before the measurement decides whether to build it: a two-document schema in a dev session, where saving one document leaves the other’s declaration rows in place, by row identity and not only by count, and refills only the registrations whose inputs the saved document feeds. The failure that assertion is aimed at is a rewrite that returns byte-identical rows, which every count-based or output-based assertion passes.

The first draft asked for R855 to land first. It has: R855 is Done, its item file gone with the state and its account in roadmap/changelog.md, and its shape is in the tree, so refresh and refreshAll already take a RefreshProgress, RefreshProgress.lines renders the two tiers, and both DevMojo and FactCapture already pass one. The sequencing preference is therefore settled by the tree rather than argued here, and the Implementation section above names the observer-carrying signatures because those are the ones that exist.

That also closes a question the first draft left open. A pass that skips every partition and says nothing is the anonymity R855 exists to remove, arriving by a new route, so a skipped partition is an observation the observer reports rather than an absence. The first draft left the vocabulary for it to R855; R855 has decided the vocabulary, so this item fits into it: one sealed arm at the per-registration tier and two counts at the pass boundary, per the Implementation section.

The sibling logging item R855 would have made this visible without reading the source, which is how both sessions that found it found it instead; it has now landed, and the section above says what this item builds on and what it owes it.

R865 is Done, and that dependency is discharged. It shipped the module move, the capture port and the store-ownership inversion, so depends-on now names R872 alone. The reason for naming either was a correctness interaction rather than a merge conflict, and R855’s shape was already in the tree; what is still owed is to the item that makes the premise true.

R872 is the hard one, and now the only one. R865 was an ordering preference: this item is sound either way round and only the reconciliation work moves. R872 is different, because the first assertion of the gate is red until it lands and the premise it enforces is false until it lands. So this item can be specified, and its rule reviewed, ahead of R872; it cannot be marked Done ahead of it. The premise section carries the argument for taking it as a dependency instead of as a fourth accepted loss.

What R872 has become, and which of its phases this item actually needs. It is four phases now. Phase one is the premise’s dependency and nothing beyond it: the cascade over the sql_, jvm_ and java_ webs, with PARTITIONED and wholesale() deleted. Phase two moves the java_ family into store_source. Phases three and four are the SDL half, and they matter to this item for a reason the premise does not cover: a skip decision on a source two graphs share is unsound today, and this is the item that makes rounds skip. store_source.stamp is one row per source, so graph A editing a shared schema file and re-walking leaves the registry stamp equal to what is on disk; graph B’s next round then reads a stamp that matches, concludes it has nothing to re-read, and keeps rows built from content that is gone. Nothing in the tree makes that decision yet, which is why the hazard is latent rather than live, and this item is what would make it live. R872’s phase four adds store_graph_source.stamp, the content identity each graph last read a source under, so the currency test becomes an equality between the two columns and each graph decides from its own record. Whether this item states its skip rule against that column or refuses to skip a shared source until phase four lands is a design question for this item, and it should be answered here rather than discovered in flight.

R876’s first slice has landed and discharges something this item would otherwise have owed. The graphitron decode used to run over a whole graph’s transcription, so refreshing one document could not rewrite the 40 source-owned graphitron_ relations without re-running the entire decode. GraphitronFactCapture.decodingInto now hands a decoder to SdlFactCapture, which drives it at each directive application it walks, so those relations are written per document like the graphql_ ones. A per-document refresh is expressible for the whole SDL family rather than half of it, and this item does not have to arrange it.

This item and R865 agree, which is why the sequencing is worth getting right. The rule below already draws the line R865 states as an API constraint: a writer never consults a claim, because a writer that has just rewritten a partition’s inputs knows they changed, and only a reader has a question. R865 says the same thing from the other end, that a consumer needing current targets asks and a consumer that does not pays nothing, and makes the store, and with it the cadence, belong to whoever opened it rather than to capture. Two statements of one rule, so the risk between them is not disagreement.

The risk this section used to carry is withdrawn, because R865 no longer ships the door it came through. An earlier draft of that item made Materializations.refresh declinable, which would have let a capture commit having refilled nothing, and this item’s rule says the capture-cadence entry point stays unconditional and records a claim per partition it refills. The two were compatible only if a capture that declined recorded no claims. R865 has since dropped every declinable path, on R876’s ground that a refresh worth skipping is a registration worth retiring, so the rule below stays true as written and no reconciliation is owed either way round.

What is left is the weaker reason, and it is still a reason: R865 moves capture and every caller of Materializations across a module boundary, and this item adds a relation and two writers in exactly that area. Writing them against the final module shape costs nothing; writing them against today’s costs a migration.

R848 asks whether the register needs to be this large at all, and it is not a dependency. R859 was the double capture; it has shipped, so what this item’s fix leaves in place is one capture per dev round rather than two, and the pass-count section states the arithmetic that follows.

R916 is why the second half is legible, and is the pattern it copies. It holds the classpath census across a session and re-reads per entry, which took the read side of a round from whole-workspace to proportional-to-the-edit and left the write and derive sides where they were. Every argument its plan makes about populations, detectors and per-file grain transfers to the schema documents, and its report is the shape the second half’s own reporting should take: a round that regressed into re-deriving everything produces correct output slowly, which is invisible without a line saying what was reused.

Two siblings from the same sweep, neither a dependency. R620 is the jar set hashed twice per round, once for the census and once for the store’s retention decision. R921 is the .java cadence hashing every source file per save. Both are the same shape as this item at a smaller scale, both are independent of the claim relation, and all three want the same measurement discipline: a count of what was read or re-derived, not a wall-clock number that a fast machine hides.