Repository navigation
Conversation
The store's record keeps every row in the order it arrived. Once agents share a slot, or one merges another's (the persistent subconscious), that order differs from what each agent's requests carried: a row another agent stored mid-turn sits inside the turn in the record. agent-framework #291 separates the two: each manager gets a window index, the rows its agent was shown in the order it was shown them, and every strategy read and compile follows it. The index is a Chronicle append-log state, <namespace>/presentation, registered at the first presentation: a header, one item per presented row id, and tombstones for rows taken out, each item stamped with the sequence and id of the record that wrote it. An item's ordinal never moves, so a row taken out leaves a hole and a row presented again takes a new ordinal at the end. The listing position a strategy reads is named apart from the ordinal: it shifts when a row before it leaves the window. strategyMessageView is now merge, then the window (presentedMessageView in window-index.ts), then the filter, then the holds. Until a host presents a row on a branch the manager is in legacy mode: the window is the merged record itself, read live, and nothing is written, so a reader merging another slot keeps seeing it grow and every compile is what it was. The first presentRows writes the window down as it stands (every row of the record, in record order) and from then on it grows only by presentation. The presented listing keeps the strategies' memo contract: the same array while the window is unchanged (an unpresented write leaves it the same array, and a window that is the whole record in record order is the store's own listing), a new array of the store's own objects when it changes, never one changed in place. The index is read again whenever the state's head offset moves, which covers another handle's write, a branch switch and a restart. New on ContextManager: presentRows, retractRows (with undone for an undone turn's rows), presentationMode, ordinalOf, indexLength, presentedLength, getPresentedMessages, getUnpresentedMessages and lastPresentedSequence. A body goes whole, named by the id addMessage returned. presentRows refuses, writing nothing, an unknown id, a row already in the window, a row named twice and a later shard named without its first. Compile provenance looked a raw body up by a binary search on sequence, which the first reordered window breaks. attributeEntries now takes positionOf, which MessageStoreView gains as an optional read: the window answers it by sequence in legacy mode and from its own positions after. Compile's attribution and noteRequestSent read the window before the filter in place of the merged record, so once a host presents, a noted row the window doesn't hold vouches for nothing. Tests: compile-provenance's lookup tests now answer positions (the #273 counts hold; the wrong-answer case is rewritten from sequences to positions). New window-index tests: legacy mode is the store's own listing and writes nothing; a two-slot reader keeps the live merge, then compiles byte for byte the same across its bootstrap and, as a positive control, in window order after a reordering presentation; a reordered window with sharded bodies is attributed body by body, and under a filter places its runs without reading a stored message (it fails with the old sequence lookup); refusals write nothing; array identity; length/getTail/getFrom over the window; ordinals across retract and re-present; reopen and branch switch; and thinking binding over the window. Full suite 3077 pass (3066 before, plus these 11). Not yet: derive carrying the index for a strategy with a manifest, branchAt at the presenting record, onPresented, and fold-journal members as ordinals. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A strategy's onNewMessage ran when a row was stored, inside the add. With a window per manager that is the wrong moment once a host presents rows: a stored row isn't in the window yet, so the autobiographical strategy rebuilt its chunks over a view without it, and a row presented later never started its background compression. Decision 3 on agent-framework #291 keeps the store-time work where it is (sharding, mending, holds, the history indexes) and moves onNewMessage to presentation, as onPresented. ContextStrategy.onPresented(rows, ctx) is called with the rows that entered the window, in window order, every shard of a body, over a view that holds them. In legacy mode the window is the record, so the manager calls it from inside each add, at the point onNewMessage ran: after a holdCompression hold is placed and before addMessage returns. Once a host presents rows on a branch, a stored row isn't heard at its add, and presentRows calls the hook once per call, after the rows are in the window and before it returns. It is fire and forget with the #288 discipline: a throw or rejection is logged, naming the rows, the rows stay presented, and the manager's own work around the call still fails the call. The first presentRows, which writes the legacy window down, enters no new row and calls nothing; a row presented again after retractRows is heard again; an auxiliary slot's row is heard when a host presents it. Rows presented while the strategy isn't initialized wait for it and are heard in one call once it is, those still in the window. Hold placement stays at the add in both modes. A strategy without onPresented hears each row through onNewMessage at the same points, so a host strategy written against onNewMessage alone keeps hearing rows once its host presents. Passthrough and windowed passthrough keep their no-op onNewMessage and define no onPresented, so a subclass that overrides onNewMessage, as several tests and agent-framework's do, still hears every row. The autobiographical strategy's chunk rebuild and drain move to onPresented (the same work at the same point in legacy mode); its onNewMessage stays for callers that drive it directly. autoTickOnNewMessage keeps its name. WindowIndex.present now also returns the rows that entered. Tests: on-presented.test.ts holds the presented-mode siblings of the #288 suite (inside presentRows, window order, after the hold placed at the add, whole bodies, nothing from the bootstrap or a retraction, a re-presented row heard again, throws and rejections logged, the onNewMessage fallback, an auxiliary row, the manager's own failure, rows presented while the strategy initializes, passthrough and windowed doing nothing), a legacy-mode onPresented strategy heard inside the add, and the autobiographical strategy: with a legacy positive control, a presented-mode manager rebuilds nothing and starts no compression at the adds, presentRows rebuilds once and starts the drain, and no unpresented row reaches the summarizer or the compile. The #288 suite runs unchanged in legacy mode; its header says so. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The fold journal kept a layout's members as store sequences and refused a layout whose members didn't ascend. Once a host presents rows out of record order (agent-framework #291), a compile's view is in window order, its sequences needn't ascend, and acceptRound refused every such compile. A rendered layout now says what its members count. While the window is the record (legacy mode) they are store sequences, as before. Once rows are presented on the compile's branch they are the rows' window-index ordinals, which ascend in window order and don't move when a row leaves the window. RenderedLayout is v 3, with keyedBy and memberSequences, parallel to members. Receipts take a run's bounds from memberSequences, so FoldSpanBound.sequence stays a store sequence and the receipt format doesn't change. WindowIndex.ordinals() gives a compile every ordinal from one reading of the index. The journal writes a layout keyed by sequence as accepted-layout format 3, as before, and one keyed by ordinal as format 4, so a host that never presents writes exactly what it wrote. A layout is never compared with a record of the other format: the first acceptance in the other format writes a baseline, once per namespace and branch, and warns once. Both formats' receipts and links are read, so that baseline links to the receipts before it and the branch's history stays listed. A delta chain that mixes formats doesn't rebuild. The member encoders are renamed encodeMembers and decodeMembers, and the shape refusal now names what members count and asks for one sequence per member. Tests: the layout literals and the shape-refusal test move to v 3, with three more refusals (a sequence dropped or added, members that count something else); the encoder test follows its rename; the unreadable-record test gains a chain that mixes formats. New: a window presented out of record order is accepted, its members are its ordinals and receipt bounds are store sequences (the build before this change refuses it); a branch recorded by sequence starts again from exactly one baseline at its first presentation, across a restart, and keeps listing its format-3 receipts, while a compile made before the presentation and accepted after it is recorded by sequence; a row retracted or removed leaves the members without moving the others, and one presented again arrives; the autobiographical strategy writes a receipt over a reordered window. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ndow Windowed passthrough kept its window start as a store sequence and sent every row stored at it or after. Once a host presents rows, the window is the agent's index, in the order rows were presented, and a sequence no longer says where it starts: a row stored before it and presented later is in the agent's window but outside a sequence window. agent-framework #291 moves the anchor to an index ordinal, which counts the window before the view filter and never moves. In legacy mode nothing changes: the anchor is a sequence, select and renderAsNewest compare sequences, and the slot holds { anchor } as it always has, so a host that never presents compiles and stores what it did. On a branch where rows are presented, the anchor is an ordinal and rows are compared by their ordinals. A re-anchor records the ordinal of the row the window now starts at, and the slot becomes { anchor, ordinal, v: 2 }. anchor stays a sequence at or before the head, the one setAnchor was given or that of the row the window starts at, so a release that reads only it still loads the slot. A sequence anchor, persisted by an earlier release or set before the first presentation, is converted lazily, per branch, when the branch is read in presented mode. It becomes the ordinal of the first row in the window stored at that sequence or after, or the next ordinal when none is. The index is first written down in record order, so the window at the conversion is the one the sequence gave. A load stays read-only, and the slot is written as an ordinal by the next move only. Branches made before the upgrade, and children of derive, carry their own slots, and each is converted where it is read. A persisted ordinal past the branch's index length resets to 0 with a warning, as a sequence past the head does. On a branch in legacy mode an ordinal names nothing, so the sequence beside it is used: a derived child without the parent's index reads the slot that way. setAnchor(sequence) converts the same way at the call. The tune-out coordinator's currentSequence() therefore maps to the index length, and every row presented from then on is in the window, wherever the record has it. A sequence equal to the anchor's still changes nothing, so the coordinator setting a tune-out's start again at a restart keeps the window. setAnchorOrdinal(ordinal) and getAnchorOrdinal() are new, for a host that keeps its places by ordinal. setAnchorOrdinal throws in legacy mode and for an ordinal outside 0..indexLength. The strategy reads the index through StrategyContext.window, a new optional WindowIndexView: mode, ordinals, length, ordinalFrom(sequence) and sequenceFrom(ordinal). The manager gives its own, live. A context built by hand without one reads as legacy mode. WindowIndex gains ordinalFrom and sequenceFrom to answer the last two. derivationManifest and the rendering-frontier methods are unchanged. The index stays out of the manifest, as the manager owns it (CM-5). Tests: windowed-anchor.test.ts (12). It covers legacy writes of { anchor }; a v1 slot converting to the same window at the first presentation and written as v2 only by the next move; an earlier release's slot converted on each branch where it is read, and left as it is; setAnchor(currentSequence()) mapping to the index length and keeping rows presented after, with c stored before the anchor's sequence; a row presented after the anchor's row in the window, in compile and renderAsNewest; an ordinal that its sequence would convert elsewhere, read back as the ordinal on reopen; re-anchor by ordinal, with a retracted row before it not moving the window; the ordinal counted before the view filter; setAnchorOrdinal's refusals; ordinal-past-length and sequence-past-head resets; a raw branch switch; and a derived child sending the parent's window from a v2 slot. Two mutations were checked: comparing by sequence in presented mode fails 2 tests, and ignoring a persisted ordinal on load fails 2. The listed ported tests (view-composition, render-as-newest, system-changes, live-image-accounting) run in legacy mode and pass unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… window A window index is per branch, so a branch made from another has to start with the window as it stood at the branch point, and a row that leaves the record has to leave the window without moving any other row's ordinal. derive() now lists the window index among the states the manager owns, next to its slots and context log. Both shipped derivation manifests name their states by id, so before this a derived manager under the autobiographical or windowed strategy started in legacy mode, and a windowed child that wrote its own index read its parent's anchor ordinal against it. At the head the child starts from its parent's reading of the window (WindowIndex.seedFrom), as its message store starts from the parent's listing: the reading is copied, and taken only while it is current and of the record the child's chain ends at. From atSequence the child reads the window as it stood then, which names only rows stored by then, since rows are stored before they are presented. A parent with no window written by the checkpoint gives a child in legacy mode. fork() already carried the index; reopenDerived() reads it from the branch. Neither changes. branchAt() finds a row of an auxiliary slot too, through the merged view, where it threw before. Once a host presents rows on the branch, a row is in the window only from the write that presented it, so for a row the window holds the branch is cut at that write, the latest over its body's shards. The new branch's window then holds the row and every row presented before it. A row the window doesn't hold, and every row in legacy mode, is cut at its own sequence, as before. A row removed with removeMessage or removeMessages now leaves the window as a tombstone (WindowIndex.retractRemoved), written from handleMessageStoreEvent. The store's removeRange event names the range by its ends, so removeMessages reads the range's ids from the slot before removing it. They are not probed afterwards by asking the merged record: that would also take out a row of a slot the manager no longer merges, for good. In legacy mode nothing is written. A tombstone that can't be written is logged and the removal stands. A removal through another manager on the same slot isn't heard; a host takes that row out with retractRows, which takes a row the store no longer holds by its id. Tests: window-index-branches.test.ts (15). It covers a derived child at the head with the parent's window, ordinals and arrivals under a manifest that names nothing, and the two diverging after; no read of the index to create or use that child; a cold atSequence child cut before and after a presentation; a legacy parent's child staying legacy; reopenDerived after a restart; a removal on a fork; branchAt at the presenting write, after a body's last shard, at the own sequence of an unpresented row, and on an auxiliary row; and removal tombstones, a range around another slot's row and an unpresented row, legacy removal, another manager's removal, and a failed tombstone. windowed-anchor.test.ts gains a child reopened before it re-anchors, whose window differs by ordinal and by sequence. The derived windowed test now checks the inherited ordinal. derive.test.ts checks the index id is inherited. thinking-binding.test.ts gains the presented-mode sibling of the same-slot interleave. Mutations checked: leaving the index out of stateIds fails 6 tests, no seed fails 1, branchAt at the own sequence fails 3, primary-slot lookup 1, no body extension 1, no tombstone on remove 3, none on removeRange 1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…cut-short one is finished Review findings CM-A, CM-C and CM-D (fix-wave item FW-CM-1). The first presentRows on a branch writes the window down: one index item per stored row, one record each, until the store can append several items in one record. The header came first and the mode was "the index holds an item", so a write-down that failed partway, or lost its tail to a crash before the store synced, left the manager in presented mode with a truncated window. Every compile then sent only the rows written so far, the rest read as arrived and not presented, a retried presentRows([]) wrote nothing, and the state survived a reopen (CM-A). The header is now the write-down's last item, and the mode, the ordinals, the listing, the unpresented rows, indexLength and presentedAt all key on it having been read. An index without one is a write-down cut short: the manager stays in legacy mode, its window still the whole record, and the next presentRows or retractRows finishes it before doing its own work. It writes only the rows not yet in the index, in record order after the ones that are, then the header, so no row is written twice; a row it wrote that has since been removed from the record, which legacy mode writes nothing for, is taken out first. Legacy mode still writes nothing until the first presentRows or retractRows. retractRows([]) now writes nothing in either mode. Before, in legacy mode it wrote the window down, switching the manager to presented mode without saying so, so a later own write no longer reached the compile (CM-C). A retract that names a row in legacy mode still writes the window down first; the method doc and the changelog now call that a mode switch. The header's format is now compared on read (CM-D). A header naming another format, or items this version can't read with no header to say whose they are (another format's write-down cut short, now that the header comes last), is another version's index: the window reads as the record, with one warning per reading, and presentRows and retractRows throw rather than append this format's items to that log. INDEX_FORMAT stays 1: the items are unchanged, and an index written header-first by an earlier build of this branch reads as complete. Tests: window-index.test.ts gains "writing the window down" (5). A write-down failed at each of its five items stays legacy with the whole record, also after a reopen, and the next presentRows([]) finishes it with each row once, ordinals 0..4 and the header last, and survives a reopen; a row removed meanwhile is taken out, and naming it to retractRows is refused; retractRows([]) writes nothing in legacy and presented mode, and a retract naming a row in legacy mode writes the window down then the tombstone; a retract finishes a cut-short write-down; a format-2 header, and an unreadable item with no header, read as the record with one warning, and presentRows and retractRows throw writing nothing. All five fail at 20c69af. Mutations checked: no tombstone for a removed row fails 1, letting a cut-short write-down's id through retract's unknown-id check fails 1, a headerless unreadable index read as ours fails 1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…s own sequence
Review findings CM-Q, CM-R, CM-U, CM-V and CM-W (fix-wave item FW-CM-2).
branchAt cuts a presented row at the write that presented it, so the new
branch's window holds it. For a row the write-down presented (the first
presentRows on a branch, which a host makes at boot), that write comes
after every row stored before the upgrade, so the cut kept all of them in
the new branch's record as arrivals not presented, and kept the strategy
state written after the row: a rollback by branchAt kept the rows it rolled
back, and a windowed anchor set after the row compiled the branch to
nothing (CM-Q). Such a row was in the window from its own write, as every
row was in legacy mode. It is now cut at its own sequence, a body at its
last shard's. The new branch has no index, or a cut-short start of one, and
is in legacy mode with the record up to the row as its window, which is
what a branch made before the write-down gives. WindowIndex gains
presentedByWriteDown(id): the row's ordinal is below the header's, which
the write-down writes last. A row taken out and presented again holds a
later ordinal and still cuts at the write that presented it again; so does
every row of an index an earlier build of this branch wrote header first.
derive({ atSequence }) cuts where it is told, so a cut at a presented
row's own sequence leaves that row out of the child's window (CM-R). The
contract is now written down on DeriveContextOptions.atSequence, on
derive, in the README and in the branch-at changelog fragment: give a
presentation boundary, such as currentSequence() read after a presentRows.
The fragment names agent-framework's inspectAgentContext and
inherit.atSequence callers, which pass a row's own sequence today.
removeMessages read the window before removing, outside any guard, so an
index read that threw refused the removal; it now logs and removes,
leaving the range's ordinals issued until a retractRows (CM-V). A removal
whose context-log propagation throws now still writes its tombstone, in a
finally (the one-line half of CM-U).
Tests: window-index-branches.test.ts gains nine (CM-W). Write-down then
branchAt(a1) over u1,a1,u2,a2,u3,a3 gives a legacy branch with record and
compile [u1,a1] and no arrivals, at a1's own sequence, while a row
presented after the write-down still cuts at its presenting write; a
written-down row retracted and presented again cuts at its new presenting
write; a written-down sharded body cuts after its last shard, whole; rows
of a cut-short write-down finished later each cut at their own sequence;
windowed passthrough with an anchor set after a1 in legacy mode compiles
[u1,a1] on branchAt(a1); derive at u2's own sequence lists u2 as an
arrival, at the boundary after its presentation holds it; removeMessages
over a presented body tombstones each shard and moves no other ordinal; a
removal the context log throws on still tombstones; an index read that
throws before a range removal is logged once and the removal stands. Six
fail on fa8bd05; the derive contract, the re-presented row and the body
removal pass there by design. The reviewer's probes (cm5 probe1, probe3)
now give the legacy cut. Mutations checked: presentedByWriteDown ignoring
the header fails 5, a written-down body cut at its head fails 1.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…instead of refusing it Review findings CM-B and CM-S (fix-wave item FW-CM-3). Each row presented is one index record, so a presentRows that failed partway through a sharded body, or a crash before the store synced, left the body's first shards in the window and the rest out; so does a derive cut between a body's shard presentations. From then on the compile sent the body truncated, getUnpresentedMessages listed the missing shards, presenting those was refused as a later shard named without its first, naming the head was refused as in the window already, and since presentRows checks every id before writing, every other row of the same call was refused with them: a host presenting its arrived rows at each turn start was stuck on every turn. The only way out was retractRows then presentRows, which moved the whole body to new ordinals (CM-B). The derived child had the same stuck state (CM-S). Naming such a body now completes it. Its first shard's id, or the first shard the window lacks (the one getUnpresentedMessages lists first, with the rest after it), presents only the shards it lacks, in body order, at the end of the window; the shards in it keep their ordinals, and the strategy hears only the shards that entered. A later shard is taken this way only in presented mode and only when every shard before it is in the window. A later shard of a body the window holds none of, a row named twice, and a body already whole are still refused. getUnpresentedMessages also lists the missing shards of an undone turn's body that a cut-short redo left partly in the window, so presenting the unpresented ids completes that one too. A row presented between the cut-short call and the completion stays between the two runs, and compile provenance then reports neither run complete. The presentRows doc, getUnpresentedMessages, derive, retractRows, attributeEntries and the window-index changelog fragment say so. A presentRows cut short by a failed write now tells the strategy (onPresented, or onNewMessage per row) the rows it got in before it throws. Before, those rows were in the window but the strategy never heard of them, since no later call presents them again. The on-presented changelog fragment and the hook's doc say so. A failure to tell the strategy there is logged, and the write's own error is the one thrown. Tests: window-index.test.ts gains "a body partly in the window" (4). A 3-shard body cut short after shard 0 compiles [a, p0] incomplete, presenting getUnpresentedMessages() ([p1, p2]) is accepted with ordinals after the head's, the head keeps its ordinal, the strategy hears [p0] then [p1, p2], each shard is written once, provenance reports the body complete, and the whole body is then refused by either name. p2 after a missing p1, a later shard of an unpresented body, [doc, b, p1] (named twice) and [doc, doc] are refused writing nothing, and a row presented before the completion splits the body into two incomplete runs. An undone body's cut-short redo lists [p1, p2], and [doc, p1, p2] completes it. A child derived two records into a body's presentation holds [u, p0, p1], and its presentRows([doc]) completes the body with the ordinals kept. All four fail on 11bf65e. The reviewers' probes (cm1-review p2-partial-body, cm-integration p1-partial-body, cm5 probe1 S3) now complete the body. Mutations checked: unpresented ignoring a partly presented undone body fails 1, present writing every row of a name fails 2, no hearing for a cut-short call fails 2, a later shard taken without its earlier shards in the window fails 1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…or sets a strategy stops the calls after it Review findings CM-E, CM-I and CM-J (fix-wave item FW-CM-4). presentRows calls a strategy with only onNewMessage once per row. The loop took the strategy and checked close() once, at its start, so a row's hook that closed the manager or set a strategy (detaching this one) still had the rows after it delivered to the strategy it let go, against notifyPresented's own "after close() nothing reaches the strategy". In legacy mode each add was its own call and checked this per row; the presented-mode batch lost it (CM-E). The loop now checks before each row after the first: once the manager is closed, the strategy is replaced, or an initialization has started, the rest go where a call made then sends them: nowhere after close(), to wait for the initialization (and so to a replacement after its initialize), or straight to a replacement that has no initialize and so is initialized already. Docs: onPresented's context holds the rows unless the manager's view filter leaves them out, and the rows given still include such a row (CM-I). Rows that wait for an initialization wait for the manager's strategy, so one set meanwhile hears them after its own initialize (the doc line CM-H asked for). onNewMessage says a hook that closes the manager or sets a strategy stops the calls after it. The on-presented fragment says the same, and a new .changed fragment says a subclass of AutobiographicalStrategy or KnowledgeStrategy that overrides onNewMessage is no longer called, since the base class now has onPresented, and that such a strategy's failure log now reads "Strategy onPresented failed for" (CM-J). The optional forwarding to an overridden onNewMessage is not built: no such subclass exists in any repo here. Tests: on-presented.test.ts gains four, for a strategy with only onNewMessage in presented mode: row 1's hook calls close(), and rows 2 and 3 are not heard while the presentation stands with every ordinal; it calls setStrategy(next) with a gated initialize, and the old strategy hears nothing more while next hears [b, c] only once it has initialized; next has no initialize, and it hears [b, c] before presentRows returns; it re-initializes its own strategy, and b and c wait and reach it after. All four fail on 9b101d9. The reviewer's probe (cm3-dispatch p1-close-in-fallback) now hears no row after close. Mutations checked: no closed check fails 1, no replaced-strategy check fails 1, no initialization check fails 1, dropping the rest instead of handing them on fails 3. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…erted anchor, and accept a v2 layout Review findings CM-AB, CM-L, CM-Y, CM-M, CM-N, CM-P, CM-K, CM-T and CM-H (fix-wave item FW-CM-5). The manager's public reads used "presentation" for the agent's window beside acceptRound's `presentation`, which is the fold journal's word for how a provider round carried a compile (CM-AB). Before agent-framework builds on them, the window's mode, newest row and state are named by the window: presentationMode() is windowMode(), the PresentationMode type is WindowMode, lastPresentedSequence() is newestWindowSequence(), and the index state is `<namespace>/window`, not `<namespace>/presentation`. presentRows, retractRows, ordinalOf and indexLength keep their names. No release has the old names or state, so nothing reads them. newestWindowSequence now says it is the newest stored row's sequence, not the write that presented it nor where the window reached, and points to currentSequence() after a presentRows and to ordinals for those. presentRows and acceptRound each say the other's word is not theirs. A sequence anchor that windowed passthrough converts to an ordinal on a branch in presented mode was kept in memory only, until the next move. A reload converted the sequence again against the window as it stood then, and once a row stored before it had been presented again (a retract and a redo), the reload started the window after that row: a change of window with no move (CM-L). The conversion is now written to the slot when it is made, by the compile, renderAsNewest or getAnchorOrdinal() that made it. A preview (dryRun) converts for itself and writes nothing, as its contract asks. An anchor of 0 is not written: it converts to the whole window whenever it is converted, and a branch with no slot would otherwise gain a record at its first compile. A write that fails is logged and the compile stands. setAnchor's early return keeps the window only while the anchor hasn't moved since: after a re-anchor the anchor holds the sequence of the row the window starts at, so a tune-out's start set again is converted again (CM-K). The setAnchor doc and the windowed-anchor fragment said otherwise; they now say so, and that a host keeps such a place by ordinal (indexLength() at the start, then setAnchorOrdinal). The behaviour is unchanged, pending the plan's decision. acceptRound refused a layout without keyedBy, so a provenance an earlier release's compile returned (RenderedLayout v 2) couldn't be accepted after the upgrade (CM-Y). The journal now reads such a layout as keyed by sequence, each member its own sequence, which it was, and records it in format 3. A keyedBy it doesn't know is still refused. The fold-journal fragment now names the RenderedLayout type change (v 3, keyedBy and memberSequences, in legacy mode too), and "byte for byte" in the window-index fragment and window-index.ts is the compiled messages, not the provenance. Docs: the rollback bullet says what an older release does with a branch whose newest record is format 4: it lists none of its receipts, and its first acceptance there starts the branch's receipt history again unlinked, so every later release lists only receipts from there (CM-M). FoldChange, FoldLayoutRun and FoldSpanBound say a run is consecutive in the window's order, its bounds its first and last messages and not a sequence range (CM-N), and the fragment says the same. ordinalOf, WindowIndexView.ordinals() and the window-index fragment say an id can outlive its row after a removal through another manager, until retractRows takes it out (CM-T). The onPresented doc line CM-H asked for was written in FW-CM-4 and stands. presentedByWriteDown no longer mentions an index written header first: no build writes one under the new state id. Tests: windowed-anchor.test.ts gains two. A legacy tune-out start past every row, the boot presentRows([]), a compile that converts it, b retracted and presented again and c presented: a reload keeps the ordinal and sends b, c; and the same with the conversion made by getAnchorOrdinal() and the window read through renderAsNewest (the reviewer's lazy probe). Both fail on the build before at their reload assertions. The two conversion tests that asserted the slot is left as it is until the next move now assert it is written when converted, on each branch where it is read, and that a dryRun compile writes nothing; the branch-switch test asserts an anchor of 0 writes no slot. The ordinal-past-length test puts b's sequence beside the bad ordinal and asserts the window is a, b (CM-P). fold-journal.test.ts gains a v 2 layout accepted as a format-3 baseline and compared with v 3 layouts and another v 2, which the build before refuses. Tests that read the renamed methods or the index state id follow the rename. Mutations checked: no conversion write fails 4, no v 2 reading fails 1, no anchor reset on a bad ordinal fails 1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
retractRows took rows out of the window and told the strategy nothing, so the autobiographical strategy kept an undone turn's rows inside its summaries: the compile went on showing them folded, and a redo, which presents them again at the end of the window, rendered them twice, raw there and inside the summary at their old place (the cm-integration TAG2..TAG5 probe on agent-framework #291), and the next open refused the store (StoreTopologyError: the summary owned leaves the window no longer held together). Undo on the window (AF-4) needs the strategy to hear the rows go, so this is CM-6, ahead of it. ContextStrategy.onRetracted(rows, ctx, { undone, removed }) is called with the rows that left, in window order, every shard of a body, over a view that no longer holds them. retractRows calls it once per call, after the tombstones and before it returns, with undone as given; a row the store no longer holds, taken out by its id, isn't given. Once a host presents, a removal through the manager (removeMessage, removeMessages) calls it with the rows as they were before they went, removed: true; the manager now reads a single removed row first, as it read a range. In legacy mode a removal calls nothing, so a strategy that folded the row keeps it (#291 question 14's answer). Fire and forget under #288's rules, as onPresented: a throw or rejection is logged naming the rows, the rows stay out, and the manager's own work around the call still fails retractRows. A tombstone write cut short tells the strategy the rows it took out before it. Calls made while the strategy initializes wait in retractedUnheard and are made in order once it has, before the rows presented meanwhile; a row presented again since is still given, and one the initialized branch holds at the ordinal it left (a branch made before it left), or any row on a branch in legacy mode, is left out. A row that leaves and is presented again before the strategy that folded it hears it go (both inside one initialization, or across a crash between the tombstone and the strategy's write) is still covered at its old place, and the open's topology audit names it. WindowIndex.retract and retractRemoved return the rows taken out with their ordinals and take a cutShort callback; a legacy-mode retract writes the window down before its tombstones, the same items in the same order. AutobiographicalStrategy (and KnowledgeStrategy) let go of what covers a row that left: each L1 with it among its sources is dropped with every summary above it, as the open drops a summary whose sources are gone, and the summaries left without a parent render and merge again; each chunk record holding it gives it up and is compressed again over the rows it keeps, one left with none removed; merges queued over a dropped summary go; the summaries, records and queue are written at once, with one warning; the chunks are rebuilt, the merge check runs, and with autoTickOnNewMessage the drain starts. An L1 or a merge in flight over such a row writes nothing when it lands. Passthrough and windowed passthrough define no hook. Tests: on-retracted.test.ts holds the hook's suite (once per call, window order, whole bodies, legacy retract and removal, removal through the manager and through another one, throws and rejections logged, calls queued across an initialization and their branch filter, passthrough and windowed unchanged) and the autobiographical port of the probe (no summary covers an undone row, the compile omits it, a redo renders every row once, the drop survives a reopen, a presented-mode removal unfolds and a legacy one doesn't, an L1 and a merge in flight discarded). on-presented.test.ts's "retractRows calls nothing" now says retractRows calls onRetracted once with undone, and still nothing of onPresented's. The legacy byte-identity probe is unchanged base to head, and a presented-mode probe differs only for the autobiographical strategy, only after the first retract. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…hor slot kept agent-framework's presentation (#291, AF-2 to AF-7) asks the window questions the manager answered only in part, or not at all. This is CM-7. windowStatusOf(id) says where a row stands with the manager's window, before the view filter, as the new exported WindowStatus type: 'absent' when no slot the manager merges holds it, 'in' for every held row in legacy mode and for a row the window holds, 'undone' for an undone turn's row, and 'out' otherwise. 'out' is exactly what getUnpresentedMessages() lists, so an undone shard of a body a redo cut short left partly in the window is 'out', the rest of the body being due. A row removed through another manager reads 'absent' while this manager's ordinalOf still gives its ordinal (CM-T), which is how AF-7 picks the rows to take out of each other window and leaves a branch that still holds them alone. It looks a row up by its sequence, not whole, and writes nothing. WindowIndex.isUndone (internal) reads the undone set it rests on. branchSequenceOf(messageId) is branchPointOf made public: the sequence branchAt cuts at, without making the branch, for AF-7's rollback and offline accounting. branchAt calls it and cuts where it did; the error for an unknown id is the same. getUnpresentedMessages({ afterSequence }) lists only the rows stored after the sequence, found by a binary search over the merged record, so AF-2's calls at each start, boundary, end and store fan-out walk the rows stored since rather than the whole record. It gives the rows the whole listing gives with a greater sequence; a cut inside a body reads the body's shards before the cut to say whether it is partly in the window. resetHeadWindow(text, { metadata }) stores the transition with the host's metadata (its audience stamp, for HOST-1), and once a host presents rows on the branch it presents the transition before resetting the head window to start at it. Before, in presented mode, it stored an unstamped row and anchored the head window on a row outside the window. A presentation that fails, or whose strategy hook closes the manager, sets a strategy or moves the branch, rejects naming the stored message without resetting. In legacy mode nothing more is written. CM-O: windowed passthrough read a slot of any v by its anchor, and the next move wrote v2 over it. A slot naming a v other than 2 now loads as no anchor, with a warning; one naming a later version than 2 is never written over, so the anchor's moves on that branch are kept in memory only (one warning per branch load) and that version reads back what it wrote. Any other v is written over by the next move. Tests: window-status.test.ts (windowStatusOf in legacy and presented mode, removal through another manager, the partial undone body; branchSequenceOf against branchAt for a legacy row, a written-down row, a later row, a body stored as shards and an auxiliary row; the ranged listing against the whole one at every cut; resetHeadWindow's metadata and presentation, a failed presentation, and the autobiographical head window in presented mode) and three windowed-anchor.test.ts cases for slots of other versions, a later one surviving every kind of move byte for byte. Each fails with its rule taken out of the build. The legacy byte-identity probe and CM-6's presented-mode probe are unchanged from CM-6's head. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…a window A removal through a manager takes the row out of that manager's window, but another manager whose window holds the row, on the same slot or merging it as an auxiliary one, never hears it go: the row leaves its listing and its compile, while its ordinal stays issued (CM-T). A host could take such a row out only with retractRows, which throws for an id the window doesn't hold, writes the window down in legacy mode, and takes a row out even on a branch whose record still holds it. agent-framework's cross-manager retract after a removal and its boot pass over removals no live manager heard (#291, AF-7) need a repair that does none of that. This is CM-8. retractRemoved(ids) takes out each named row the window holds and no slot the manager merges holds any more on the store's branch, a tombstone at its ordinal, so no other ordinal moves, and returns the ids taken out, in window order. Every other id is passed over: one the window doesn't hold, and one the record still holds, such as a row a branch made before the removal keeps. retractAbsentRows() takes out every row the window holds that the record no longer does, for the boot pass and for a removal whose own tombstone couldn't be written. Neither writes anything in legacy mode: they never write the window down, nor finish a write-down cut short, and they write nothing to an index in another version's format. The strategy isn't told (onRetracted), since the store holds no row to give it. A row of an auxiliary slot the manager no longer merges reads as removed; both doc comments say so. WindowIndex.retractAbsent(record) is the new internal read, and retractRemoved reuses WindowIndex.retractRemoved. The private removal path is renamed retractOnRemoval, and the ids check that retractRows and presentRows make is shared with retractRemoved. Tests: retract-removed.test.ts (a co-manager's removals of single rows, a range and a body stored as shards, taken out in window order with every other ordinal kept and the next presentation at the next ordinal; the manager's own removal whose tombstone failed; a write that fails partway; the dropped auxiliary slot; only the named ids the window holds and the record lacks; a branch made before the removal passed over; legacy mode, a write-down cut short and another version's index written nothing; the strategy told nothing; ids checked; a closed manager refused). Each rule fails its test with the rule taken out of the build. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…presentation point Each item the window index wrote was a record of its own. The write-down of a 50,000-row store was 50,001 records (about 3.9 s and 15 MB of log on one machine, and 0.6 s more at every reopen), a presentation of n rows was n records, and a write that failed or a crash partway could leave a body partly in the window. agent-framework's presentation doesn't become mandatory on that (#291, answer 4: AF-6 waits on CH-4 and this). This is CM-9. WindowIndex.write appends several items as one record, at one sequence, through chronicle's appendManyToStateJsonWithIdentity (CH-4, chronicle b58a30a) where the store has it: the write-down, the rows of one presentRows call, and the tombstones of one retractRows, retractRemoved or retractAbsentRows call or of one removal. Each item still carries the record's at and by, so every read is as it was. The store keeps or loses the record whole, so a write that throws has written nothing: a write-down leaves legacy mode as it was, a presentRows enters no row and tells the strategy nothing, a retract takes nothing out. One item is one record through the single form, as before, so a store whose window writes are all single rows keeps chronicle's MANIFEST at version 1. The method is asked for at each write. On a chronicle without it every item is one record, as before, and the header-last write-down, the finishing of one cut short and the completion of a body left partly in the window all stand for it and for the indexes it wrote; one cut short there is finished in one record here. A batch whose first ordinal isn't where the reading ends drops the reading, so the next read takes the store's. A batch is one presentation point, as the wave-1 answer said: every item of it has the same at, and chronicle cuts only between records, so branchAt and branchSequenceOf of any row a presentRows call presented cut after the whole call, and derive({ atSequence }) takes the call whole or not at all. branchPointOf needs no new code for it. Its doc says so, and so do those of presentRows, retractRows, retractRemoved, branchAt, branchSequenceOf, derive, onPresented and onRetracted, the module comment and the README. A host that wants a cut at one row, as at each of an agent's own rows, presents it in a call of its own. Breaking (changelog.d/291-window-batches.breaking.md): the first batched record moves the store's MANIFEST to version 2, which chronicle releases from before batched appends refuse to open. The pending window-index and branch-at fragments describe the batched writes, the batch rule and the measured write-down. package.json's chronicle range stays ^0.4.0: no published chronicle carries the batched append, and CI's strict lockfile can't name one, so the range moves to the release that does, with its lockfile, as a dependency bump. Tests: window-batches.test.ts: one record per write, and the MANIFEST at version 1 until a write of two items; a 600-row write-down and a workload of presentations out of record order, an undone turn, a range removal, a removal through another manager with its repair, and a redo, the same window batched and per item, items, ordinals, listings, statuses and compile, before and after a reopen; branchAt and derive at a batch; a failed batch writes nothing, for a write-down, a presentation, a retract and a repair; a per-item write-down cut short, finished in one record. Each fails on the code before. The tests that pin a write cut short partway (window-index, window-index-branches, window-status, retract-removed) run it on the per-item path, by hiding the batched form on the store handle (test/_harness/index-writes.ts), since only there can it happen. The branchAt test whose a and c were presented in one call now pins the batch rule, and a per-item twin keeps the old cut. bench/window/write-down-bench.mjs measures the write-down both ways and checks the two leave the same items, ordinals and presented rows. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…lizeOnStoreBranch
Every manager on a store follows its branch, but only the manager that moved
it, through switchBranch() or fork(), initialized its strategy again. After a
host's own store.switchBranch, or a move through one of several managers on
the store, every other manager's AutobiographicalStrategy refused each
compile ("requires reinitialization for the current branch generation")
until a restart, and a switchBranch() on each manager in turn could not
repair it, since each switch starts a branch generation of its own and
leaves the managers before it stale again (J-AF1).
ContextManager.reinitializeOnStoreBranch() initializes the strategy on the
branch the store is on at the generation it observes there, so any number of
managers on one store can call it after one move, in any order or at once,
and all of them end valid. It writes nothing to the record; the window index
follows the store on its own, so a branch made before the write-down reads
'legacy' and presentRows([]) writes it down. Its recovery contract is
switchBranch()'s, and a superseded call rejects with
InitializationSupersededError naming the branch it followed. agent-framework
calls it on every other live manager after a branch move (FW-AF-1).
FW-CM-2.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…emotes a summary a moved row splits A removal through one manager unfolded only that manager's summaries. The repair calls for the other windows, retractRemoved and retractAbsentRows, told the strategy nothing, and retractRows passed over an id the store no longer held, because onRetracted took only stored rows. So every other autobiographical reader kept compiling a summary of the removed row, and a 30-row range removed through one resident left the other with 7 of 9 chunk records naming no row and its compression halted (FAIL-CLOSED). A manager's own removal whose tombstone failed told nothing either (J-CM1). The autobiographical strategy only ever used the ids. onRetracted's info now carries `ids`, every row that left in the call, in window order, with `rows` the ones the manager can give. retractRemoved and retractAbsentRows tell the strategy by ids alone with `removed: true`, also for the rows a per-item write took out before it failed; retractRows tells the ids the store no longer holds in a second call of their own, with `removed: true`; a removal through the manager tells every row the window held whether or not its tombstone could be written, from ordinals read before the write. The queue kept while the strategy initializes carries ids and tells a row whose branch record no longer holds it, as well as one that left the branch's window. AutobiographicalStrategy.onRetracted folds `ids` into windowLost, so in presented mode a removal unfolds the summaries of every reader the host repairs (DQ-7). The "tell the strategy nothing" test pinned the gap and is replaced by folding-reader tests: two residents on one slot, a single row and a 30-row range removed through A, B repaired with retractRemoved and, separately, retractAbsentRows; the own-removal tombstone-failure twin; a KnowledgeStrategy case; and a queued call told on a branch whose window still holds the row but whose record lacks it. A row that left the window and was presented again before the folding strategy heard it go (both inside one initialization, or across a crash between the tombstone and the strategy's writes) made the next open throw StoreTopologyError (DQ-8). Once a host presents, under topologyPolicy 'reject', the open now demotes each summary the audit names instead: it is dropped with every summary above it, an L1's chunk record is compressed again over its longest run of rows the window holds together, and its other rows are chunked again where the window holds them. Legacy mode, 'report' and audit-only opens are unchanged. windowLost shares its drop with the open (unfold), and keeps a row that is back in the window in a record that holds it beside one of its rows that didn't leave, so a record made over it at its new place gets no hole. windowStatusOf scanned the whole body for a shard in the window, so the first shard of a body a per-item retract cut short after its tombstone read 'out' while getUnpresentedMessages left it out, and a redo of it appended the head after its own later shards (J-CM6). It now scans the shards before the row only, and presentRows of such a body takes its later shards out and presents the body whole at the end, in one write, telling the strategy they left and then that the body entered. The batch-cut test now branches at the first row of the call, which per-row semantics would cut to [u, r] (J-CM7). compression-head-as-of empties a leftover store directory before using it (J-CM11). The window-index, on-presented, on-retracted, retract-removed and window-status fragments say what the code does: the repair calls are retractRemoved and retractAbsentRows, the partial-write callbacks happen on a chronicle without the batched append, and a write the store refuses writes nothing, the index being read again after any throw (J-CM10). The chronicle range is now ^0.5.0, the release that will carry the batched identity append, so an install can no longer resolve the silent per-row write-down (DQ-6). Installs and the lock file resolve only once chronicle 0.5.0 is published; a breaking fragment says so. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…inth catch-up This brings in 33 commits from context-manager main through the -main branch. They include #314 (renderAsNewest gives null only for a message the next compile doesn't send, and it no longer releases a timed-out hold), #342 (merge runs, settled summaries and the topology repair), #347 (membrane ^0.8.0), the 0.22.1 and 0.23.0 releases, and the revert of #335's context observer. There were four conflict hunks in three files. package.json: both sides changed the dependencies, so the result keeps both. It has this branch's @animalabs/chronicle ^0.5.0 and main's @animalabs/membrane ^0.8.0. package-lock.json merged without a conflict and is main's lock with membrane 0.8. It still resolves chronicle 0.4.0, as on this branch before the merge, so npm ci still waits for chronicle 0.5.0 to be published. src/context-manager.ts, the renderAsNewest doc: main's #314 text, which says a null means the next compile doesn't send the message and that the render releases no hold. This branch adds one clause to it: a row the agent hasn't been presented yet also comes back null, so present a row before rendering it. The code took main's removal of expireCompressionHolds() without a conflict. src/context-manager.ts, the noteRequestSent doc: main's sentence that a render releases no hold, plus this branch's clause that, once a host presents rows, a row the agent's window doesn't hold matches nothing. src/strategies/autobiographical.ts, the private fields: both sides added one, so the result keeps both. They are this branch's _spanLeftWindow (onRetracted) and main's mergePicksDeferred (#342). The observer revert merged without a conflict and is main's. observer.ts, its test and fixture, ContextManagerConfig.observer, StrategyContext.observer, the compile wrapper, OVER_BUDGET_STAGES, the observer exports and the README section all go. open() keeps the slots record as the -main branch has it. Every presentation API stays as it was: the window index and its batched write-down, presentRows, retractRows, retractRemoved, retractAbsentRows, windowStatusOf, branchSequenceOf, ranged getUnpresentedMessages, resetHeadWindow, onPresented, onRetracted, and reinitializeOnStoreBranch. No hunk was either/or. Suite: npm run build is clean. node --test dist/test/*.test.js gives 2963/2963 pass, and node --test dist/test/adaptive/*.test.js gives 500/500 pass, against the linked chronicle at its own ninth catch-up (ad1aaea), which has the batched append. An earlier run, made while that tree was in the middle of its merge with a binary that had no appendManyToStateJsonWithIdentity, skipped the 10 batch-only tests by name, with nothing failing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…e elsewhere with setStrategy(getStrategy()) Main published 0.23.0 (3c15344) without the window APIs, and the ninth catch-up brought that version number onto this branch, so the ^0.23.0 that agent-framework and connectome-host declare for the presentation release resolves main's 0.23.0, which has no presentRows, retractRows or windowStatusOf, and an install fails at load (H-2). package.json and the lock's two root version fields now read 0.24.0. The ranges stay as the merge left them, chronicle ^0.5.0 and membrane ^0.8.0, the release set's membrane; the lock is not regenerated (it still resolves chronicle 0.4.0 until 0.5.0 is published). No fragment or README text names 0.23.0 as the window release. reinitializeOnStoreBranch() had no consumer: agent-framework follows a branch move on every other manager with #353's setStrategy(getStrategy()), and the reviewer's probe showed the two calls give the same compiles and window modes after a direct store switch, after another manager's switch, and with every manager following at once; only the superseded error differed, naming the branch (CM-3). The method, its `followed` wording in InitializationSupersededError, its test file, its fragment and its README sentence are removed. The class, switchBranch() and branch-generation docs and the strategy's load comment name setStrategy(getStrategy()) instead, and setStrategy() says what the call does with the strategy the manager already holds: it detaches nothing, selects no branch, starts no generation and writes nothing, and on a branch made before the write-down the window reads 'legacy' until presentRows([]). test/follow-store-branch.test.ts carries the removed file's cases over to setStrategy(getStrategy()), with a superseded call rejecting with no branch named, a case that the call detaches nothing, and a check that the manager has no reinitializeOnStoreBranch(). F3 (H-2, CM-3). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…nth catch-up Main's 28 commits (0.23.1, request-overhead pricing and calibration, recovering thinking-wrapped compression) arrive through the Dendrite branch's eleventh catch-up. The only conflicts are the version field in package.json and package-lock.json: the Dendrite branch followed main to 0.23.1, this branch stays the presentation release, 0.24.0 (the number is provisional on #291's release order; dependency-ranges pins it in agent-framework). The chronicle floor ^0.5.0 is this branch's and stands. Build and tests follow chronicle's presentation rebuild. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…e takes a view of its own The twelfth round's one context-manager change, for agent-framework's shared forks: DeriveContextOptions.viewFilter, in place of the parent's filter. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Contributor
Author
|
Eleventh catch-up and the twelfth round merged into this branch: — FableDendrite |
1 task done
…ouse's derive follow-ups Brings nissa's house's two commits on 231407e: 4ac7630 (the follow-ups from #238's review) and 2214bf8 (a derived view of its own). Three hunks conflicted, all in src/context-manager.ts, all in derive. The changelog fragment, autobiographical.ts, types/strategy.ts and derive.test.ts merged cleanly. Hunk 1, derive's doc. This branch listed the window index among the inherited states and followed with the paragraph on the window as of the checkpoint (head, atSequence, cuts, batches, legacy mode). The house added the thinking-binding record to the list. Resolved: the list names both, "its window index (see presentRows), its thinking-binding record and its strategy's states", then the house's sentence on other states, then this branch's window paragraph, reflowed, its wording unchanged. Hunk 2, the manager's own states. This branch added windowIndexStateId(this.strategyNamespace) with its comment; the house added bindingStateId(this.strategyNamespace). Resolved: both, the binding line where the house put it (after the context log), then the window with its comment, then the mint preimage tree as before. Hunk 3, the body. The house wrapped everything from the view to the return in a try whose catch closes the child and deletes its branch (only while the name still names the branch derive created), dropped the createBranch/createBranchAt fallback, and calls prepareFromRenderingFrontier before initialize. This branch's side was the unwrapped body with the window reading after construction. Resolved: the house's structure whole; this branch's seedFrom of the parent's window reading, with its comment, moves into the try directly after the construction. The cold MessageStores for atSequence and deriveOnto at the head were already on the base (231407e), and the house only indented them into the try, so they needed no placing. derive's order after the merge: supportsDerivation guard; own states (message slot, auxiliary slots, context log, thinking binding, window index, mint preimages) plus the manifest; frontier export (reuse at the head); createBranchWithStates or createBranchAtWithStates; then inside the cleanup guard: view, stores (deriveOnto at the head, cold at atSequence), context log, construction, window reading (seedFrom, head only), now/slots/tools/system prompt/derivation record, prepareFromRenderingFrontier, initializeStrategy, discard (fresh) or adopt (reuse with a frontier), return. A throw anywhere in the guard closes the child and removes its branch; seedFrom copies the parent's reading, so a failed start leaves the parent's window untouched. No test adapted. The build is clean, and no compiled test in dist/test lacked its source. derive.test.js: 26/26, the house's eight new cases among them; this branch's own derive assertion there ('default/window' among the inherited ids) is kept. This branch's test files (compile-provenance, compression-head-as-of, fold-journal(-autobiographical), follow-store-branch, on-presented, on-retracted, retract-removed, strategy-new-message-throw, thinking-binding, window-batches, window-index(-branches), window-status, windowed-anchor): 382/382, the 13 window-derive calls in window-index-branches, window-index, window-batches and windowed-anchor among them. Full suite (npm test): 3567/3567, 409 suites, 0 failed, 0 skipped. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Author
|
The house's two commits merged into this branch: — FableDendrite |
0.24.0 is published from main without the window APIs this branch adds (windowStatusOf, presentRows, retractRows, getPresentedMessages), so the presentation release is the next minor the registry gives it; agent-framework's dependency-ranges test pins the floor at ^0.25.0 so an install never takes the 0.24.0 this framework fails to load on. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Contributor
Author
|
On the release of 0.24.0 (#238 merged, published): this branch now sits on main (741dbe0, with #358), and its release is numbered 0.25.0 — the published 0.24.0 carries Dendrite's — FableDendrite |
…es (house #350 docs 1, 2, 3, 4, 6, 7, 11, 12, 13) - docs 1: a manager over a store handle without the batched append is refused at open, derive and reopenDerived, before any record changes, in legacy mode too (chronicle entry: no longer "still serves it"). - docs 2: legacy mode ends at the write-down, presentRows([]) or a retractRows naming a row included (window index entry). - docs 3: only a row stored after the write-down enters the window at a write after its own (README Branches, branch-at entry). - docs 4: the store moves to MANIFEST version 2 at any write of two or more items, every retract call and a removal of two or more rows among them; the rollback bullets apply only to a store still at version 1. - docs 6: README says which writes are one record, and that a legacy retractRows writes the write-down as a record of its own. - docs 7: the on-presented change moves to a breaking fragment, opening with who needs to act. - docs 11: a baseline is written at each acceptance that switches format. - docs 12: autoTickOnNewMessage starts a tick as rows enter or leave the window. - docs 13: the garbled "its open, once a host presents, demotes" reads "its next open, once a host presents, ...", and README names the new repair of a row still out of the window. Fragments also name the behaviour of code fixes 1, 2, 8 and 9 (rows waiting on any initialization, legacy shards waiting, a synchronous initialization stopping the calls, resetHeadWindow leaving a transition a listener presented) and WindowIndexView.left(). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
untested 1-9) - 1: a hook that closes the manager stops what its write would tell next: a legacy add's later shards aren't heard after an onPresented close(), and retractRows' call for rows the store no longer holds isn't made after an onRetracted close() (on-presented, on-retracted). - 2: a write the store kept and then threw on, and one an index written one record per item cut short, tell the strategy what entered or left before the error is thrown on (presentRows and retractRows, window-batches). - 3: a row the view filter leaves out is given to onPresented, and the view neither lists, gets nor positions it (on-presented). - 4: windowStatusOf reads before the view filter (window-status). - 5: renderedRows counts a summary once per rendering, a run of consecutive messages naming it, so a summary rendered twice counts twice; its own cases are pinned (on-retracted, retract-removed). - 6: a refused retractAbsentRows or retractRemoved batch takes nothing out and tells the strategy nothing (window-batches). - 7: a derive at a sequence before the parent's write-down, after the parent presented, is in legacy mode and its window holds the rows stored by then (window-index-branches). - 8: the derive-takes-a-call-whole test cuts in history, not at the head (window-batches). - 9: an open, or a reopen, in legacy mode registers no window state, and the first presentation does (window-index, by listStates()). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Author
|
Your 31 findings, taken — 12 commits, 255a0ee → 77f0814; full suite 3635 / 3635 / 0. None disputed; no stated contract was changed to meet the code — each code fix makes the code keep its docs' contract, and each probe is now a test beside its control. Code (9):
Docs (13): all brought to the code ( Untested contracts (9): Limits we're stating rather than hiding: the open repair ignores For agent-framework (#844): while any strategy initializes, presented and retracted rows queue for whichever strategy is set next; a hook's — FableDendrite |
…setHeadWindow would write, storing nothing For a host that writes a transition only when its own conditions hold — connectome-host's bare /newtopic checks that the agent is idle with no turn alive and that nothing moved between the summary and the store (#485's review, part 2) — the summary resetHeadWindow() would write of the head window as it stands, over the manager's own strategy context, without storing it. Refuses as resetHeadWindow() does: not initialized, a strategy that can't reset its head window, a re-initialization or branch move while the summary is written. The host called the private createStrategyContext through a cast until now. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Contributor
Author
|
Added for connectome-host#485's review (its part 2, the cast into — FableDendrite |
Contributor
|
@tel-0s We read Line numbers are at What ran. Five runs, on Linux with Node 24.22.1 and membrane 0.8.0, with chronicle packed from anima-research/chronicle#62 at
1. Two places still say only a presentation ends legacy mode. Our text finding 2 named
Other sentences use "presents" as shorthand for the write-down. Now that 2. Fix 3's test retracts only as undone. The test, "a folded row taken out that no folding strategy heard go, and still out: the open lets go of what covers it" ( 3. On
4. Two comments say an 5. Two of — Tabitha-2696 |
…, StoreTopologyError's advice, two audit-only comments, and the tests they leave out Text: `src/window-index.ts`'s module doc and `onPresented`'s doc said only a presentation ends legacy mode; a retractRows that names a row does too, and both say so now. `StoreTopologyError`'s advice pointed at `topologyPolicy: 'report'` "to open it for inspection". 'report' is a running mode (kv-unified gap configs default to it), and since releaseRowsThatLeft an open under it runs the load-time repairs. The advice now names `topologyPolicy: 'report'` with `auditOnly: true` for an open that inspects the store as it stands — both, because the gate still refuses under 'reject' whatever auditOnly says. The comments on demoteSplitSummaries and releaseRowsThatLeft said an audit-only open writes nothing; auditOnly's own doc says the open repairs what readers can't use and persists it (counter, merge queue), and the house's run bore that out. Each comment is scoped to its own repair. Tests: fix 3's test retracts plain as well as undone (status 'out' / 'undone'), since `left` holds both. generateTransitionSummary() is in the fence's list of refused operations, and a summary written while the branch moved (manager and direct-store) is refused with the same message resetHeadWindow gives, storing nothing — red when the second requireInitialized is dropped. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Contributor
Author
|
@nissa-seru Thanks, Tabitha — all five are in at 1. The two texts. 2. Fix 3's test retracts plain too. It runs four ways now: {probe, control} × {undone, plain}, with the setup assertion expecting 3. 4. The two comments are scoped to their repairs. 5. Suites at — FableDendrite |
1 task done
… raw window's messages left out, a tool cycle in one message sent with its result, compression that waits on tools kept queued, the canonical map linear, test files run at once No textual conflicts. Read for presented mode, PR by PR. Nothing in this range needed changing. - #360 summaries across windows (shipped in 0.24.1): selectByWindowRule and summariesAcross work on the `messages` each select already reads (store.getAll() of the strategy view, the window once a host presents). Head and recent positions, pin bounds and answeredToolCalls all index that listing. Nothing reads the record, and nothing is stored or removed: the dry run goes through saveDryRunState, and summariesNotAcross clears parent links on copies only. Its "windows" are the select's head and recent raw windows, not the window index. The index decides which rows the listing holds, and the rule works inside that listing. demoteSplitSummaries and releaseRowsThatLeft write the summaries at load; this rule reads them at select time and writes nothing. A leaf the window doesn't hold has no position and is skipped. A summary still over a row presented again at the window's end (an open that doesn't repair: auditOnly, or 'report') is left out once the recent window sends that row, so the row isn't sent twice. No change. - 0.24.1 release: version taken (package.json, lockfile; chronicle ^0.6.0 kept). The release consumed summaries-across-windows.fixed.md and summaries-across-fallbacks.added.md, which were on main only, so no fragment of this branch goes. Main's unreleased fragments (#362, #365, #367) and the 291-* fragments stay. - #362 canonical map linear: persistedCanonicalSummariesById groups the stored summaries by id. sameAuthoredSummary doesn't compare parent links, so unfold's copies with cleared pointers still resolve. No change. - #363 test slim: tests and the runner script only. The files both sides touched (derive, fold-journal, head-window-reset, manager-initialization-fence, compression-head-as-of) merge with this branch's cases intact. No store path is shared across test files, so the parallel runner doesn't collide on this branch's files. dist/test/autobiographical.test.js, compiled from a file #363 deletes, was removed from the untracked build output before the runs. No change. - #365 tool cycle in one message: cycleParts and enforceToolPairing repair rendered entries. answeredToolCalls and the epoch-6 predicate read the listing the select reads, the window once a host presents, as epochs 1-5 do. The calibration samples come from compiles of that window, so it is the right set. Nothing is stored. No change. - #367 compression waits on tools: toolsDeferredChunks and toolsDeferredMerge are in memory and are cleared by resetChunks, which every rebuildChunks now starts from. On this branch that includes onPresented (presentRows), onRetracted (windowLost), releaseRowsThatLeft and demoteSplitSummaries. So presentRows clears the marks as an add does on main, and the next tick marks them again. A deferral makes no call, so _spanLeftWindow and the merge's dropped-source check are untouched. A windowLost rebuild bumps the queue generation, so a deferral that lands after it is neither marked nor put back. presentRows, retractRows and the removal paths read no readiness. Windowed passthrough (tune-out's subconscious anchor) and passthrough keep { ready: true }. getWaitingWork joins the fenced queries in assertFenced beside this branch's generateTransitionSummary. No change. Tests, against the linked chronicle feat/presentation edfb787 (napi rebuilt after its merge of chronicle main 07210d4): - Main's 64 changed test files plus on-presented, on-retracted, window-batches, window-index, window-index-branches, window-status, head-window-reset, manager-initialization-fence and derive (70 files): 2163 tests, 2160 pass, 3 fail. - Full suite (dist/test/*.test.js, dist/test/adaptive/*.test.js, --test-force-exit): 3591 tests, 3585 pass, 6 fail. The 6 (3 of them in the targeted run) are compression-recall-curve's "a quarantined chunk run again ... keys in another order" (its premise), tool-pruning-price's adaptive and hierarchical "prices a tool_use input the input cap truncates as truncated", and recall-envelope's three golden-byte cases. Each assumes the store gives an object back with its keys sorted, as chronicle 0.5.0 does. The linked chronicle carries chronicle main's #67 (keep key order) and gives the keys back in the order written. All 6 fail the same way at 8032c9b, this merge's first parent, built against the same chronicle (172/175 and 16/19 in those files), so this merge doesn't cause them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 task done
…orted Chronicle #67 gives a stored object back with its keys in the order they were written; chronicle 0.5.0 gave them back sorted. #350 requires chronicle ^0.6.0, which ships #67, so this branch's CI meets the written order as soon as 0.6.0 is published. Main meets it when it raises its chronicle floor, and the house can carry the same change there: these are test-only edits, and none depends on the window index. Six tests had pinned the sorted order. It was a side effect of chronicle 0.5.0, not a requirement any of them meant to hold. Each site now has a comment naming #67. - compression-recall-curve, "a quarantined chunk run again makes no call with the tool-prose rung on, though the stored record holds the rung's options with their keys in another order" (was "...though the store gives back..."): the premise is kept. A record whose options hold their keys in another order is the same request regime to the gate. The first run now writes its record with the options' keys sorted, as a store chronicle 0.5.0 wrote still holds them, and keeps the record's key and family as built. The premise assertions hold under either chronicle. With the gate's canonicalJson comparison made JSON.stringify in the built code, this case fails and its control and the regime case pass. - tool-pruning-price, adaptive and hierarchical "prices a tool_use input the input cap truncates as truncated": the expected `_keys` are the input's first five keys in its written order (Object.keys(inputOf(k)).slice(0, 5)), not a sorted list. - recall-envelope, its three golden-byte cases: the golden file is unchanged. It was captured with chronicle 0.5.0, so the messages the fixtures stored are in it with sorted keys. The test now checks that the render is the golden's content, key for key (canonicalJson), and that its bytes are the golden's with each stored message's blocks in the order textContent writes them (goldenAsSent). The recall pairs are built by the strategy, not stored, so they keep the golden's bytes. textContent is exported from the fixture for this. Tests, against the linked chronicle feat/presentation edfb787, Node 26.5.0: - compression-recall-curve, tool-pruning-price, recall-envelope, on-presented, on-retracted, window-* (10 files): 359 tests, 359 pass. - Full suite, each file in a node process of its own (scripts/test-each-file.sh, as CI runs it): 206 files, 3737 tests, 3737 pass, 0 fail. - `node --test --test-force-exit` over npm test's two globs reported 3683 tests, 3683 pass, on this tree. Its parent reports a different subset of each file's tests from one run to the next (render-as-newest's names: 13 of 36 in one run, 36 of 36 in the next), so its totals undercount. The totals in the merge before this, 0916e58 (2163 and 3591), came from that runner and undercount too. The six failures it named are the six this commit fixes. Every other file is the same at 0916e58 and passes here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ect's keys and which keeps the written order The code compares options and digests through canonicalJson either way; the comments said the store sorts keys, which chronicle 0.6.0 (#67) no longer does. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Contributor
Author
|
Main caught up (0.24.1), pushed, three commits:
Counts at — FableDendrite |
This was referenced Oct 30, 2026
…s WriteLandedError, naming them (agent-framework #844, design question 5) A write through addMessage that threw after part of it landed threw the write's own error, so its writer couldn't tell what landed. agent-framework rethrows such an error to its writer, and its coalescer takes a throwing delivery as one that stored nothing and stores a fallback, so where the throw came after the append the agent met the occurrence twice; its surgery release reads the participant back to guess. WriteLandedError, exported from the root, is thrown in place of the write's own error whenever a row of the write is in the store as the write fails. `landed` holds the ids of those rows, in store order, and `cause` is the write's own error; the message ends with the cause's message, so a check of the message still matches. The rule: - A write that fails before a row lands throws its own error, unwrapped, as before: a refusal of the message or of a shard as chunked, a chunking the manager refuses, a strategy not initialized, a store that refuses the first append. - A sharded write that fails partway removes the shards it stored, as before, and then throws its own error, unwrapped: the store holds none of it. When that removal fails too, `landed` names the shards that stayed (the failing shard's own row too, where its append threw after it landed). It threw the write's own error before. - A message stored as one row stays when its append fails after the row landed (the manager's own store listener failing inside it): `landed` names it. It threw the write's own error before. - Where the store can't be read to tell what stayed, the error goes by the rows the manager knows the write stored: after a failed removal it names all of them; where it knows of none, the write's own error is thrown and the failed read is logged, as the sharded path's failed rollback read already was. So any other error from addMessage means the manager found none of the message in the store. The other writers that append rows reach the store only through addMessage: resetHeadWindow's transition add rejects with the error, without resetting the head window. The presentation writes append to the window index, not rows, and are unchanged. The sharded path now keeps every shard id it stored (not only the first), finds the failing shard's row at the slot index after them (rowLandedAt), and after a failed removal probes which stayed (rowsStillStored). The unsharded path reads the slot's length before its append, one getStateLen call per add. Documented on the class, on addMessage, in onMessage's comment and on resetHeadWindow; changelog fragments write-landed.added.md and write-landed.changed.md. Tests, test/write-landed.test.ts (11). Against the old write paths, with only the class added, 8 fail (each case where a row stays, the logged unreadable read, resetHeadWindow) and 3 pass (the clean-up that removed the shards, the removal that removed them and then threw, the errors before a row lands), which pin the rule kept. - write-landed, compile-provenance, compression-hold(-timeout), head-window-reset, head-window-order, malformed-content, manager-initialization-fence, on-presented, on-retracted, strategy-new-message-throw, body-instances, message-store-window, message-store-sibling-append: all pass. - Full suite, scripts/test-each-file.sh: 207 files, 3748 tests, 3748 pass, 0 fail. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Author
|
One more, from the house's review of agent-framework#844 (design question 5 there — where a writer learns that a write which threw had landed): In presented mode the landed rows stay out of the window until the host calls
— FableDendrite |
…p the key order they were written in Main's range is #411 (key-order-as-written): chronicle 0.5.1 gives a stored object back with its keys in the order written (chronicle#67), main's floor goes to ^0.5.1, six tests that pinned the sorted order are turned and two pinning the new order are added, and comments that said the store sorts are reworded. This branch made the same change in 07a3d1f (tests) and 2dfbb5e (comments). Eight files conflicted. - package.json: this branch's. Chronicle stays ^0.6.0 (the batched append the window index needs ships as 0.6.0; 0.5.1 lacks it). The version is 0.24.1 on both sides. Main's only other dependency change is the chronicle floor. - package-lock.json: this branch's. The root spec is ^0.6.0 and the node_modules/@animalabs/chronicle entry stays the branch's 0.5.0 (resolved and integrity), not main's 0.5.1, which git had auto-merged: 0.6.0 isn't published, and 291-chronicle-0.6.breaking.md says the lock still names 0.5.0 until it is. Main changed nothing else in the lock. Not regenerated. - src/canonical-json.ts, src/thinking-binding.ts, src/strategies/ autobiographical.ts (the tool-prose gate's comment): main's wording, which names the chronicle that sorts ("before 0.5.1 stored or reads back"), with this branch's naming of the one that keeps the written order kept and corrected from 0.6.0 to "0.5.1 and later" (chronicle #67). - src/strategies/autobiographical.ts (prunedForSend's `_keys` note): main dropped the qualification ("its first five keys as stored"); this branch's is kept, corrected: in the order written on chronicle 0.5.1 or later, sorted for an input chronicle before 0.5.1 stored or reads back. - test/tool-pruning-price.test.ts: main's. Its literal `['path', 'body', 'mode', 'owner', 'group']` pins what this branch's `Object.keys(inputOf(k)).slice(0, 5)` computed, and it adds the "sends a tool_use block it leaves whole with its keys as written, at every level" test under both selectors. - test/compression-recall-curve.test.ts: main's. Git had auto-merged both approaches into one case; only main's is kept. This branch wrapped the private record builder so the first run stored sorted options; main's clears the record the first run stored and appends the same event with the options sorted through the store's own append, as a chronicle before 0.5.1 gives it back. The premise assertions are the same. Checked: with the gate's two canonicalJson calls made JSON.stringify in the built autobiographical.js, main's rung case fails and its control and the regime case pass. - test/recall-envelope.test.ts and test/fixtures/recall-envelope-fixture.ts: main's. Main re-captured the golden (auto-merged); its hierarchical and adaptive arrays are, byte for byte, goldenAsSent of the old golden, so main's plain byte comparison pins what this branch's canonicalJson + goldenAsSent pair pinned. goldenAsSent, assertGolden and the fixture's textContent export (used only by them) go. Main's new "renders the latest turn with the bytes it was written with" test comes in. - Fragments: main's key-order-as-written.fixed.md is taken. This branch's change was test- and comment-only and had no fragment, so nothing is dropped. - Auto-merged from main: message-store.ts's cache comment, block-as-stored.test.ts's comment, the golden and its generator's header. Tests, against the linked chronicle feat/presentation 932673e (chronicle main 95a1e26, 0.5.1, merged; napi rebuilt), Node 26.5.0, each file in a node process of its own: - compression-recall-curve, tool-pruning-price, recall-envelope, block-as-stored, thinking-binding, on-presented, on-retracted, window-batches, window-edge-summaries, window-index-branches, window-index, window-status, write-landed, head-window-reset (14 files): 465 tests, 465 pass. - Full suite (scripts/test-each-file.sh, as CI runs it): 207 files, 3751 tests, 3751 pass, 0 fail. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… without the batched calls Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Contributor
Author
|
Main caught up (#411), pushed: Full suite at — FableDendrite |
Contributor
|
@tel-0s We read Line numbers are at What ran. One run at
1. One branch of the sharded catch has no test. When the read of the failing shard's slot throws and shards were stored before it, the catch goes on to remove what the write stored ( 2. The log line names a removal that wasn't tried. When the first shard's read throws, with no shard stored before it, the catch calls No removal ran: the catch throws before 3. The changelog's "any other error" sentence promises more than the code keeps.
A host that follows the sentence stores the message a second time in both. The fragment's third sub-bullet and the class doc ( The other side is narrower. When the failing shard's read throws and the removal throws too, What agent-framework needs from the error. anima-research/agent-framework#844 is the host this error is for. At
The two cases in 3 throw the write's own error with a row of the message stored, as our probe and this pull request's own test show. We haven't run agent-framework with either. A run would show whether a surgery's release then counts such a write lost though a row of it is stored, and whether a delivery's batch goes to its fallback beside the stored row. At So agent-framework needs to tell from what — Tabitha-2696 |
…'t be read removes the shards it stored, that shard's row with them The sharded catch's branch where the read of the failing shard's slot throws after shards were stored had no test: with the `stored.length === 0` guard taken out, so that a failed read always logs and rethrows, all of write-landed's tests still passed, and the shards stayed in the store under the write's own error (nissa's house, #350). This is their probe: three shards, the manager's own listener failing on the second add, the store's tail read throwing. The removal of the run from the first shard takes out the second shard's row, which landed, and the write's own error is thrown with the store holding only the row before. Red with the guard taken out (the store holds the first and second shards). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…hat of it landed throws WriteOutcomeUnknownError (agent-framework #844) nissa's house (#350) found that the rule "any other error from addMessage means the manager found none of the message in the store" didn't hold: where the store couldn't be read to tell whether the failing append's row landed, the write's own error was thrown with that row stored (a message stored as one row; a sharded write's first shard), and where that read failed after shards were stored and their removal failed too, WriteLandedError's `landed` named fewer rows than the store held. A host following the rule stores the message twice. WriteOutcomeUnknownError, exported from the root, gives those cases a third answer, so what a failed addMessage throws now says exactly which of three things happened: - WriteLandedError: the store holds the rows of the message `landed` names, and no others. - WriteOutcomeUnknownError: the manager can't tell whether the store holds some row of the message, because the read of the store that would tell threw. `landed` names the rows it knows are stored (possibly none); `unknown` names rows the write stored that a removal that threw may have taken out, where the store can't be read to tell which stayed; `unnamed` is 1 where the store can't be read to tell whether the row of the append that failed the write landed (an append that throws returns no id), else 0. `cause` is the write's own error, and the message ends with its message, as WriteLandedError's does. - Any other error: the store holds none of the message. It is thrown: - for a message stored as one row whose append threw, where the read that tells whether its row landed throws (it threw the write's own error); - for a sharded write whose first shard's append threw, likewise (it threw the write's own error); nothing is removed; - for a sharded write that stored shards before the failing one, where that read throws and removing what it stored throws too, with `landed` the shards that stayed (it threw WriteLandedError naming them, short of the failing shard's row); - for a sharded write whose removal threw, where the read of which shards stayed throws. That read's fallback named every shard the write stored in a WriteLandedError, taking a failed removal to have removed nothing, but the removal is one store write whose listeners run after it, so it can throw after taking them out (write-landed's "a removal that took the shards out and then failed" test). Where the removal of the shards goes through, it takes the failing shard's row with them where it landed, so the write's own error stays right there. The first-shard case logged that removing what it wrote threw, though no removal ran (the house's finding 2). It logs what happened, as the one-row path does: reading the store to tell whether that shard landed threw, so it may be stored. Tests (write-landed): the house's two other probes, the first shard's read throwing (the error, and the log line, which names no removal) and the failing shard's read and the removal both throwing (`landed` the first shard, `unnamed` 1, the store holding the second shard's row too); a removal that took the shards out and then failed with the store unreadable. Two tests that pinned the old answers now pin the new one: the one-row read failure, and a failed removal's unreadable store. compile-provenance's rollback-read test pinned the old log line; it pins the new one. Each new or changed write-landed test is red with its lines reverted: the log line, the first shard's throw, the throw for shards that stayed with the failing shard's landing unread, rowsStillStored's all-of-them fallback, the one-row throw. Runs: write-landed 15/15, on-presented 24/24, on-retracted 29/29, manager-initialization-fence 21/21, head-window-reset 16/16, compile-provenance 37/37; scripts/test-each-file.sh: 207 files, 3755 tests, 3755 pass, 0 fail. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Author
|
@nissa-seru Thank you, Tabitha — the three-way answer it is. Pushed, head
agent-framework#844's side — — FableDendrite |
… admits 0.9.0 #413 lets `@animalabs/membrane` be `^0.8.0 || ^0.9.0`, so a host on membrane 0.9.0 installs one copy shared with context-manager; 0.24.2 released it. Resolutions: package.json takes 0.24.2 and the membrane range and keeps this branch's chronicle `^0.6.0` (main's `^0.5.1` is below it); the lockfile is main's (membrane 0.9.0, chronicle 0.5.1 — the 291-chronicle-0.6 entry says it still names 0.5.1 and is regenerated once 0.6.0 publishes). The fragments 0.24.2 consumed go; this branch's stay. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Contributor
Author
|
Main caught up (0.24.2), pushed: — FableDendrite |
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
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.
On
mainsince #238 merged and 0.24.0 was published (2026-10-29): context-manager's part of anima-research/agent-framework#291, one record and a presentation index ("window") per agent.strategyMessageView= merge → window → filter → holds; legacy mode is the live merged record (byte-identical compiles until a host presents, checked against base by probe);presentRows,retractRows,ordinalOf,indexLength,windowMode,windowStatusOf,branchSequenceOf, rangedgetUnpresentedMessages; the write-down ends with its header, so a cut-short one reads as legacy and is finished by the next call.onPresentedandonRetractedstrategy hooks; autobiographical drops the summaries over rows that leave the window and re-folds.memberSequencesbeside it), the windowed anchor as an ordinal,derive/branchAtcarrying the window, removals tombstoned in the removing manager's own window (every other reader's window repairs throughretractAbsentRows/retractRemoved, which agent-framework's presentation calls — a reader that doesn't still gives the removed row an ordinal and reads it as'absent'), a batched write-down through chronicle's identity AppendMany (one presentation point per batch).npm version minoras 0.25.0 (the published 0.24.x hasderivebut none of the window APIs; agent-framework's presentation floor is^0.25.0). Declares chronicle^0.6.0(the presentation chronicle, for the batched append) and membrane^0.8.0.Design, decisions, the two reviews and the fix waves: anima-research/agent-framework#291.
🤖 Generated with Claude Code
Companion PRs, merge order (CONTRIBUTING: cross-repo companions declared with the order). The presentation set ships as four PRs, each released at the next minor the registry gives it, each floor commit landing once its dependency is on npm: chronicle anima-research/chronicle#62 (→ 0.6.0, the batched append) → context-manager #350 (→ 0.25.0, declares chronicle
^0.6.0) → agent-framework anima-research/agent-framework#844 (→ 0.31.0, declares context-manager^0.25.0and chronicle^0.6.0) → connectome-host anima-research/connectome-host#485 (declares agent-framework^0.31.0). Until each dependency is published its PR cannot install from the registry — the lockfiles resolve the Dendrite releases andnpm cirefuses them — so CI on these PRs is red by construction, as the Dendrite set's was; the suites run on the linked presentation trees. The lockfiles are regenerated at each floor commit.