isomorphic-jj 1.11.0 → 1.12.1

package/CHANGELOG.md

@@ -1,5 +1,144 @@
 # Changelog
 
+## 1.12.1 — 2026-09-27 — Conflict type shape + README status refresh
+
+A cross-library documentation/typing audit flagged four things to verify
+against current code; two turned out already fixed (`converge()`'s JSDoc
+already documents N-way behavior as of #32/#35's 0.4.0 follow-up), one is
+tracked as a design question instead of guessed at (see the "public,
+untyped internal components" issue on `jj.graph` and its siblings), and
+this release covers the two that were genuinely stale.
+
+### Fixed
+
+- **`Conflict`/`ConflictType` in `src/types.d.ts` didn't match the shape
+  `ConflictModel` actually constructs.** `sides` was typed as `TreeRef[]`
+  (an array of tree hashes); every real `Conflict` object has `sides` as
+  an *object* — `{ left, right }`, `{ base, left, right }`, or (for
+  `converge()`'s N-way case, `ConflictModel.createNWayConflict()`)
+  `{ base, versions }` where `versions` is
+  `Array<{ commitId, content }>`. The interface was also missing
+  `message`, `timestamp`, and the optional `driverFailed`/`driverError`
+  fields that `_createConflict()` actually sets, and `ConflictType` was
+  missing the `'path'` and `'driver-conflict'` values `ConflictModel`
+  uses. Added a `ConflictSides` type covering both the two-way and N-way
+  shapes and corrected `Conflict` to match reality. Type-only change (the
+  `.d.ts` file has no runtime code), so nothing about the library's actual
+  behavior changes — this only fixes what TypeScript consumers see.
+- **README's "Project Status" section was frozen at the pre-`@johnhenry`
+  rename numbering.** It read "Current Version: 0.3.0" (actual:
+  1.12.0), cited "1823 tests" (actual: 1874), and its roadmap stopped at
+  0.3.0 with no mention of 0.4.0's N-way `converge()` (#32/#35), the
+  1.9.0 scoped/unscoped version-lineage merge (#36), or the 1.9.1–1.12.0
+  operation-log reliability pass (#37–#39, #41, #43, #45, #48). Also
+  corrected the provenance note's "reached v1.7.0 before the rename" to
+  the CHANGELOG's own recorded **v1.8.0** ceiling (see the 1.9.0 entry
+  below), and clarified that "Not yet 1.0" refers to API stability, not
+  the version number (which is already past 1.0 purely because merging
+  the two lineages forced it above the unscoped side's prior ceiling).
+  The Node 26 / `engines.node` note was checked too and was already
+  accurate — no change needed there.
+
+### Testing
+
+1874 tests passing, 0 skipped; lint (0 errors), format:check, typecheck,
+and all 12 `examples/*.mjs` green; coverage 97.39% statements / 90.11%
+branches / 99.08% functions / 97.63% lines (branch gate is 90%).
+
+## 1.12.0 — 2026-09-27 — op-recording gaps left by #43/#45's fixes (#48)
+
+Follow-up to #43/#45 (below). Walking every op backward then forward now
+lands correctly in 49 of 60 restores (up from before); the 11 misses were
+five distinct gaps, all in the operation-recording machinery those fixes
+introduced or depend on, plus one pre-existing bug in `operations.list()`
+discovered while writing regression tests for the others.
+
+### Fixed
+
+- **The descendant rebase performed by `edit()`/`snapshot()`/
+  `autoSnapshotWorkingCopy()` was never itself recorded in the operation
+  (R1).** `_rebuildDescendants()` mutates every rebased descendant via
+  `graph.updateChange()`, but had no way to hand its callers each
+  descendant's pre-rebase state — so `undo()`/`operations.restore()` had
+  nothing to reverse the rebase with, even though the ANCESTOR's own
+  content change was (already) correctly captured. Added an optional 4th
+  parameter, `outChangeSnapshot`, populated with `{[descendantId]:
+  fullRecordBeforeRebuild}` for every descendant actually mutated; all
+  three call sites now pass their own `changeSnapshot` object through so
+  it lands in the same operation record.
+- **Restoring to a `conflicts.resolve()` (or `merge()`/`converge()`/
+  `moveChange()`) op could restore the resolved file but leave the
+  change's conflict state unresolved (R2).** `computeGraphReversal()`
+  recovers "conflict state right after `landingOp`" by scanning for a
+  LATER op's own "before" snapshot — which only exists if some later op
+  also touches conflicts. Conflict resolution is usually a one-off event
+  with nothing later re-touching the `ConflictModel` at all, so landing
+  exactly on it found no candidate and silently left whatever conflict
+  state already happened to be live untouched (file content usually
+  recovered correctly anyway, by coincidence — some unrelated later op
+  touching the same file's `changeSnapshot`). `conflicts.resolve()`,
+  `merge()`, `converge()` (unresolved case), and `moveChange()` now also
+  record `conflictsSnapshotAfter` — the result of the mutation THEY
+  performed — and `computeGraphReversal()` falls back to it when nothing
+  later reveals the answer.
+- **A file changed directly on disk and picked up by
+  `autoSnapshotWorkingCopy()` (not the explicit `snapshot()` API) had no
+  "before" copy recorded anywhere (R3) — described as "silent
+  re-snapshot" when it also rebases descendants.** `autoSnapshotWorkingCopy()`
+  — the implicit reconciliation `status()`/`read()`/`describe()`/etc.
+  trigger on every call — mutated the graph (and rebased descendants) with
+  no operation recorded at all. A later `undo()`/`operations.restore()`
+  had nothing to reverse it with, and since the same function runs again
+  on every subsequent call with no drift left to detect, a real,
+  one-time content change looked exactly like it had simply never
+  happened. Now records a real operation (mirroring the explicit
+  `snapshot()` API, `description: 'auto-snapshot working copy'`) whenever
+  it actually refreshes content — gated on the same `added`/`modified`/
+  `deleted` check it already uses, so a no-op call still records nothing.
+- **After `edit()` moves `@` to an older change, `log()` could hide a real,
+  undescribed tip with real work in it, and `edit()` recorded only its own
+  target in `view.heads`.** `_computeHiddenOrphans`'s `autoCreated ||`
+  branch (needed for two undo-artifact cases — see its doc comment) has no
+  way to distinguish "a synthetic scaffolding change that's still
+  discardable" from "a real, live tip the user simply isn't checked out on
+  right now" once the FLAG is set once at creation and never cleared.
+  `edit()` recording only its own target in `view.heads` (correct back
+  when `edit()` was a pure checkout, wrong now that it also commits the
+  change being left) meant this package's own "explicit, maintained set of
+  live heads" proxy never saw the other, real tip at all. Fixed two ways:
+  `edit()`'s recorded `view.heads` now uses `computeCurrentHeads()` (every
+  non-abandoned change with no non-abandoned children) instead of
+  `[args.changeId]`; and `RevsetEngine` now takes the operation log as a
+  constructor param and `_computeHiddenOrphans` adds the latest op's
+  `view.heads` to its `trackedHeads` signal, alongside the working-copy
+  pointer and every bookmark/tag target — the "explicit, maintained set of
+  heads" this package's own doc comment already said real jj's View keeps,
+  now actually wired through.
+- **`operations.list()` reversed its own internal array in place instead
+  of a copy, silently scrambling operation order on the SECOND call within
+  a session.** `oplog.list()` returns its live internal array by
+  reference (by design — `computeGraphReversal()` and others need the
+  real, oldest-first list); `operations.list()`'s own `.reverse()` (to
+  present newest-first) mutated that same array as a side effect. Calling
+  it twice — a completely reasonable thing to do (list history, do
+  something, list history again) — un-reversed it back to oldest-first,
+  and anything recorded via `oplog.recordOperation()` in between landed
+  appended to what was, at that moment, the WRONG end. Found while writing
+  a regression test for the fixes above (two `operations.list()` calls
+  around one `autoSnapshotWorkingCopy()`), not from the issue's own repro
+  — but real and, in principle, capable of corrupting `undo()`/`redo()`/
+  `operations.restore()` for any caller that also calls
+  `jj.operations.list()` earlier in the same session. Fixed by copying
+  before reversing.
+
+  See `tests/integration/issue-43-restore-reliability.test.js`'s new
+  "issue #48" suites (8 new tests across all five gaps above) and
+  `tests/unit/core/revset-branches-coverage.test.js`'s new oplog-signal
+  suite (2 tests) for the hidden-tips fix specifically. All verified with
+  a negative control: reverting just the source changes fails exactly
+  these new tests while every pre-existing test still passes, confirming
+  they exercise real behavior rather than being tautological.
+
 ## 1.11.0 — 2026-09-26 — edit() of an older change rebases its descendants (#45)
 
 Part 5 of #43 (parts 1-4 shipped in 1.10.0 / #44), previously punted because

package/README.md

@@ -1020,10 +1020,10 @@ repo/
 
 ## Project Status
 
-**Current Version**: 0.3.0 (`@johnhenry/isomorphic-jj`; same library/API lineage as the old `isomorphic-jj`, which reached v1.7.0 before the rename — see the provenance note at the top of this file)
-**Test Coverage**: 1823 tests passing, ~97% statements / 91% branches
+**Current Version**: 1.12.0 (`@johnhenry/isomorphic-jj`; same library/API lineage as the old `isomorphic-jj`, which reached v1.8.0 before the rename — see the provenance note at the top of this file, and the CHANGELOG's `1.9.0` entry for how the scoped/unscoped version lineages were merged back together)
+**Test Coverage**: 1874 tests passing, ~97% statements / 90% branches
 **JJ CLI parity**: tracks Jujutsu through v0.45.1
-**Status**: Actively developed; broad JJ CLI semantic parity, used in the examples/apps in this repo and in [JJHub](#family). Not yet 1.0 — API surface can still shift; pin a version and read the CHANGELOG before upgrading.
+**Status**: Actively developed; broad JJ CLI semantic parity, used in the examples/apps in this repo and in [JJHub](#family). Not yet 1.0 in the API-stability sense (the version number is past 1.0 only because merging the scoped/unscoped lineages forced it above the unscoped side's prior ceiling, not because the API is frozen) — API surface can still shift; pin a version and read the CHANGELOG before upgrading.
 
 **Completed:**
 - ✅ v0.1: Core JJ experience (stable IDs, undo, bookmarks, revsets)
@@ -1036,6 +1036,9 @@ repo/
 - ✅ 0.1.0 (post-rename): Parity refresh tracking jj through **v0.44** — `tag.track()`/`tag.untrack()`, the `builtin_log()` revset alias, and `file.search({ nameOnly: true })`; `git_refs()`/`git_head()` documented as deprecated (jj removed both in v0.43). See [CHANGELOG.md](./CHANGELOG.md) for what was deliberately left for a maintainer call (`jj run`, fetch-time remote tag/bookmark import).
 - ✅ 0.2.0: Storage-layer audit fixes — same-process storage locking, `undo()` reverting in-place graph/tag mutations, ambiguous change-id detection, categorized `push()` error codes, a conflict-marker newline fix, atomic protobuf writes, and open-ended revset ranges (`..b`, `a..`, `::`). See [CHANGELOG.md](./CHANGELOG.md).
 - ✅ 0.3.0: Parity refresh tracking jj through **v0.45.1** — a working `/browser` entry (async `createBrowserFS()`, bundle-safe protobuf schema loading, no stray Node-only imports), `undo()`/`operations.restore()` reverting graph rewrites with real progressive undo/redo, `squash()`/`abandon()`/`edit()`/`new()` fully syncing content instead of only metadata, `rebase()` performing a real three-way merge and recording conflicts, and the new `converge()` command (jj v0.45.0) to auto-resolve divergent commits. See [CHANGELOG.md](./CHANGELOG.md).
+- ✅ 0.4.0: `converge()` generalized from pairwise to N-way — any number of divergent copies of one change id resolve in a single call, matching how jj's own underlying engine already treats divergence internally (issue #32). See [CHANGELOG.md](./CHANGELOG.md).
+- ✅ 1.9.0: Scoped (`@johnhenry/isomorphic-jj`) and unscoped (`isomorphic-jj`) version lineages merged into one shared version going forward, with both names dual-published on every release.
+- ✅ 1.9.1 – 1.12.0: Operation-log reliability pass — `undo()`/`operations.restore()` correctness across write/snapshot/squash/rebase/abandon/edit, `log()` visibility fixes, and recording gaps in descendant rebases and conflict-resolution ops (issues #37–#39, #41, #43, #45, #48). See [CHANGELOG.md](./CHANGELOG.md) for the full per-fix breakdown.
 
 See [ROADMAP.md](./ROADMAP.md) for detailed plans, and [CHANGELOG.md](./CHANGELOG.md) for the release history.
 

package/dist/index.cjs

@@ -2532,13 +2532,23 @@ class RevsetEngine {
    * @param {any} [userConfig] - User configuration instance (optional)
    * @param {any} [bookmarkStore] - Bookmark store instance (optional, v0.4)
    * @param {any} [tagStore] - Tag store instance (optional, v1.5)
+   * @param {any} [oplog] - Operation log instance (optional, issue #48) —
+   *   see `_computeHiddenOrphans`'s doc comment for why this is needed.
    */
-  constructor(graph, workingCopy, userConfig = null, bookmarkStore = null, tagStore = null) {
+  constructor(
+    graph,
+    workingCopy,
+    userConfig = null,
+    bookmarkStore = null,
+    tagStore = null,
+    oplog = null
+  ) {
     this.graph = graph;
     this.workingCopy = workingCopy;
     this.userConfig = userConfig;
     this.bookmarkStore = bookmarkStore;
     this.tagStore = tagStore;
+    this.oplog = oplog;
   }
 
   /**
@@ -3225,11 +3235,24 @@ class RevsetEngine {
    * excludable. Real jj instead tracks an explicit, maintained set of
    * heads in its View (updated as operations run — abandoning/squashing a
    * change removes it, rebasing children onto a new parent removes the
-   * old parent, etc.). This package doesn't thread the operation log's
-   * `view.heads` through to the revset engine, but the working-copy
-   * pointer plus every bookmark/tag target is the closest available
-   * proxy for "what's actually still in play" — anything only reachable
-   * from those, not from every dangling graph leaf.
+   * old parent, etc.).
+   *
+   * Issue #48: the working-copy pointer plus every bookmark/tag target,
+   * alone, missed a real case this rule needs to cover: `edit()`-ing @ to
+   * an OLDER change leaves the change you edited AWAY FROM still fully
+   * live (nobody abandoned/squashed/rebased it away) — but it's a
+   * DESCENDANT of the new @ (not an ancestor), so it's absent from
+   * `reachable` no matter what. If that change also happens to be
+   * `autoCreated` (e.g. it came from `new()`) and was never `describe()`d,
+   * the `autoCreated ||` branch below — needed for the two undo-artifact
+   * cases documented above it — incorrectly swept it up too, hiding a real
+   * tip with real work in it. The operation log's `view.heads` (now
+   * correctly threaded through via the `oplog` constructor param) is
+   * exactly the "explicit, maintained set of heads" real jj's View keeps —
+   * every mutating operation records the actual live heads as of right
+   * after it ran (see `computeCurrentHeads()` in repository.js), so the
+   * latest one is the accurate, low-cost substitute for a full View this
+   * package doesn't otherwise maintain.
    *
    * @param {any[]} allChanges - `graph.getAll()`
    * @returns {Promise<Set<string>>} change IDs to exclude
@@ -3253,6 +3276,18 @@ class RevsetEngine {
         if (tag && tag.changeId) trackedHeads.add(tag.changeId);
       }
     }
+    if (this.oplog) {
+      try {
+        const headOp = await this.oplog.getHeadOperation();
+        if (headOp && headOp.view && Array.isArray(headOp.view.heads)) {
+          for (const headId of headOp.view.heads) {
+            if (headId) trackedHeads.add(headId);
+          }
+        }
+      } catch {
+        // oplog not loaded/available — fine, just no op-based roots.
+      }
+    }
 
     const reachable = new Set();
     for (const headId of trackedHeads) {
@@ -7994,6 +8029,13 @@ async function createJJ(options) {
    *   - changeSnapshot: { [changeId]: fullRecordBeforeThisOpRan }
    *   - view.fileSnapshot: on-disk file state right BEFORE this op ran
    *   - conflictsSnapshot: ConflictModel state right BEFORE this op ran
+   *   - conflictsSnapshotAfter: ConflictModel state right AFTER this op ran
+   *     (issue #48, R2) — conflicts.resolve()/merge()/converge()/
+   *     moveChange() all record this alongside the "before" value, purely
+   *     as a fallback for landing exactly ON that op with nothing LATER
+   *     also touching conflicts (see below) — every other kind of state
+   *     here only ever needs a "before" value, because it's recovered from
+   *     a LATER op's own before-snapshot, not from itself.
    *
    * Deliberately NOT reverted: changes an operation newly *created* (via
    * graph.addChange() — new(), squash()'s synthetic empty working-copy
@@ -8065,6 +8107,20 @@ async function createJJ(options) {
       }
     }
 
+    // Issue #48 (R2): the loop above recovers "conflicts state right after
+    // landingOp" from a LATER op's own "before" snapshot — but that only
+    // exists if some later op also touched conflicts. When landingOp is
+    // itself the last op to ever touch conflicts (routine for
+    // conflicts.resolve()/merge()/converge()/moveChange() — nothing
+    // naturally re-touches the ConflictModel afterward), the loop finds
+    // nothing and this used to silently leave conflict state exactly as it
+    // already happened to be, which is only correct by coincidence. Fall
+    // back to landingOp's OWN recorded `conflictsSnapshotAfter` (the actual
+    // result of the mutation IT performed), when present.
+    if (conflictsSnapshot === undefined && landingOp.conflictsSnapshotAfter != null) {
+      conflictsSnapshot = landingOp.conflictsSnapshotAfter;
+    }
+
     return { changeSnapshotToApply, fileSnapshot, conflictsSnapshot };
   };
 
@@ -8269,7 +8325,24 @@ async function createJJ(options) {
         const change = await graph.getChange(wcId);
         if (change) {
           const oldFileSnapshot = change.fileSnapshot ? structuredClone(change.fileSnapshot) : {};
-          change.fileSnapshot = await snapshotFilesystem();
+          // Issue #48 (R3 / "silent re-snapshot"): this used to mutate the
+          // graph (and rebase descendants) with no operation recorded at
+          // all — the comment above even called it out as reconciling
+          // state "silently". That meant an out-of-band disk edit picked
+          // up here was gone for good the moment a later undo()/redo()/
+          // operations.restore() landed anywhere: there was no op in the
+          // log capturing the transition, so nothing could reverse it, and
+          // — since this is exactly what status()/describe()/read()/etc.
+          // trigger on every call — it fired again on the very next such
+          // call with no drift left to detect, making a real, one-time
+          // content change look like it had simply never happened. Same
+          // treatment as the explicit snapshot() API now gets: capture the
+          // "before" state and record a real operation, so this is exactly
+          // as reversible as calling jj.snapshot() by hand.
+          /** @type {Record<string, any>} */
+          const changeSnapshot = { [wcId]: structuredClone(change) };
+          const newFileSnapshot = await snapshotFilesystem();
+          change.fileSnapshot = newFileSnapshot;
           await graph.updateChange(change);
 
           // Issue #45: if the working-copy change isn't a leaf (e.g. we
@@ -8284,10 +8357,28 @@ async function createJJ(options) {
           // in the same enclosing scope and this function only ever runs
           // after `jj` is fully constructed, so the self-reference is safe
           // (same pattern used elsewhere in this file, e.g. `jj.new(...)`).
+          // Issue #48 (R1): pass `changeSnapshot` through as the 4th arg so
+          // a rebased descendant's pre-rebase state is captured too — see
+          // `_rebuildDescendants`'s doc comment.
           const descendants = await jj._findDescendants(wcId, null);
           if (descendants.length > 0) {
-            await jj._rebuildDescendants(wcId, null, oldFileSnapshot);
+            await jj._rebuildDescendants(wcId, null, oldFileSnapshot, changeSnapshot);
           }
+
+          await oplog.recordOperation({
+            timestamp: new Date().toISOString(),
+            user: await getUserOplogInfo(),
+            description: 'auto-snapshot working copy',
+            parents: [],
+            changeSnapshot,
+            view: {
+              bookmarks: {},
+              remoteBookmarks: {},
+              heads: await computeCurrentHeads(),
+              workingCopy: wcId,
+              fileSnapshot: newFileSnapshot,
+            },
+          });
         }
       } catch {
         // Best-effort content refresh; tracking state is already updated.
@@ -8490,7 +8581,7 @@ async function createJJ(options) {
   });
 
   // Create revset engine with the middleware-wrapped graph (v0.4: added bookmarkStore)
-  const revset = new RevsetEngine(graph, workingCopy, userConfig, bookmarks, tags);
+  const revset = new RevsetEngine(graph, workingCopy, userConfig, bookmarks, tags, oplog);
 
   /**
    * Helper to resolve conflicts with different strategies (v0.5)
@@ -9261,6 +9352,21 @@ async function createJJ(options) {
               await mkdirp(fs, join(dir, pathParts.slice(0, -1).join('/')));
             }
             await fs.promises.writeFile(fullPath, markerText, 'utf8');
+            // Keep the working-copy tracker in sync with this out-of-band
+            // write (issue #48, discovered via R2's fix) — otherwise the
+            // NEXT autoSnapshotWorkingCopy() call (status()/read()/etc.)
+            // sees a stale tracked mtime for this file, reports a false
+            // "modified", and now (since autoSnapshotWorkingCopy() records
+            // a real operation for that — see its own doc comment) records
+            // a spurious extra op immediately after this one. Every other
+            // direct-to-disk write in this file (write(), syncWorkingCopyFiles)
+            // already does this; this was the one gap.
+            const markerStats = await fs.promises.stat(fullPath);
+            await workingCopy.trackFile(conflict.path, {
+              mtime: markerStats.mtime,
+              size: markerStats.size,
+              mode: markerStats.mode,
+            });
           }
         }
       }
@@ -9269,6 +9375,15 @@ async function createJJ(options) {
       change.parents = [newParent];
       await graph.updateChange(change);
 
+      // Issue #48 (R2): the AFTER state, for landing exactly on THIS op
+      // when nothing later also touches conflicts — see
+      // computeGraphReversal's doc comment and conflicts.resolve()'s
+      // matching `conflictsSnapshotAfter`, which this mirrors.
+      const conflictsSnapshotAfter = {
+        conflicts: Object.fromEntries(conflicts.conflicts),
+        fileConflicts: Object.fromEntries(conflicts.fileConflicts),
+      };
+
       // Record operation
       await oplog.recordOperation({
         timestamp: new Date().toISOString(),
@@ -9277,6 +9392,7 @@ async function createJJ(options) {
         parents: [],
         changeSnapshot: { [changeId]: changeSnapshotBefore },
         conflictsSnapshot,
+        conflictsSnapshotAfter,
         view: {
           bookmarks: {},
           remoteBookmarks: {},
@@ -9900,9 +10016,18 @@ async function createJJ(options) {
           // matching real jj's automatic rebase-on-edit. edit() itself is a
           // pure checkout and never mutates content, so this is the actual
           // moment content changes and the right place to propagate.
+          // Issue #48 (R1/R3): pass `changeSnapshot` through as the 4th arg
+          // so a rebased descendant's pre-rebase state is captured into the
+          // SAME op this method records below, not lost the moment
+          // `_rebuildDescendants` mutates it.
           const descendants = await this._findDescendants(wcId, null);
           if (descendants.length > 0) {
-            await this._rebuildDescendants(wcId, null, changeSnapshot[wcId].fileSnapshot);
+            await this._rebuildDescendants(
+              wcId,
+              null,
+              changeSnapshot[wcId].fileSnapshot,
+              changeSnapshot
+            );
           }
         }
       } catch {
@@ -10265,12 +10390,20 @@ async function createJJ(options) {
             // isn't a leaf (we'd edit()'d into an ancestor), its descendants
             // still have the OLD content and need the same rebase-on-edit
             // treatment applied at the other two commit sites.
+            //
+            // Issue #48 (R1): pass `changeSnapshot` itself as the 4th arg
+            // so every rebased descendant's pre-rebase state lands in the
+            // SAME object this method already records into the op below —
+            // previously only `previousChangeId`'s own before-state was
+            // captured, so undo()/operations.restore() had no way to
+            // reverse the descendant rebase itself.
             const descendants = await this._findDescendants(previousChangeId, null);
             if (descendants.length > 0) {
               await this._rebuildDescendants(
                 previousChangeId,
                 null,
-                changeSnapshot[previousChangeId].fileSnapshot
+                changeSnapshot[previousChangeId].fileSnapshot,
+                changeSnapshot
               );
             }
           }
@@ -10316,7 +10449,17 @@ async function createJJ(options) {
         view: {
           bookmarks: {},
           remoteBookmarks: {},
-          heads: [args.changeId],
+          // Issue #48: previously hardcoded to `[args.changeId]` -- correct
+          // back when edit() was a pure checkout (the target WAS the only
+          // thing that could plausibly have changed), but edit() now also
+          // commits the change being left (see above), which can leave a
+          // second, real, still-live tip that isn't the edit target at all
+          // (e.g. `previousChangeId` itself, if it has no descendants).
+          // Recording only the target here silently dropped that other
+          // live head from `view.heads` -- see `_computeHiddenOrphans` in
+          // revset-engine.js, which reads the latest op's `view.heads` as
+          // one of its signals for "still actually in play."
+          heads: await computeCurrentHeads(),
           workingCopy: args.changeId,
           fileSnapshot: fileSnapshotBeforeSwitch,
         },
@@ -10652,7 +10795,20 @@ async function createJJ(options) {
        */
       async list(opts = {}) {
         await oplog.load();
-        let ops = await oplog.list();
+        // `oplog.list()` returns its OWN internal array by reference, not a
+        // copy — discovered while fixing issue #48: calling this method
+        // TWICE in the same session (e.g. once to capture a "before" op,
+        // then again later to check what got recorded) used to reverse
+        // that internal array a second time, silently un-reversing it and
+        // scrambling the order any operation recorded in between landed
+        // at. `.slice()` (with no args, i.e. a full copy) unconditionally,
+        // before ever limiting or reversing, so `.reverse()` below always
+        // mutates a throwaway copy — this method itself was the only
+        // caller that needed to be non-destructive; `oplog.list()`'s own
+        // contract (return the live list, oldest-first, for internal
+        // reversal-computation callers like computeGraphReversal) is
+        // unchanged.
+        let ops = (await oplog.list()).slice();
 
         if (opts.limit && opts.limit > 0) {
           ops = ops.slice(-opts.limit);
@@ -11623,12 +11779,20 @@ async function createJJ(options) {
         for (const conflict of detectedConflicts) {
           await conflicts.addConflict(conflict);
         }
+        // Issue #48 (R2): the AFTER state — see conflicts.resolve()'s
+        // matching `conflictsSnapshotAfter` and computeGraphReversal's doc
+        // comment for why landing exactly on this op needs it.
+        const conflictsSnapshotAfter = {
+          conflicts: Object.fromEntries(conflicts.conflicts),
+          fileConflicts: Object.fromEntries(conflicts.fileConflicts),
+        };
         await oplog.recordOperation({
           timestamp: new Date().toISOString(),
           user: await getUserOplogInfo(),
           description: `converge ${changeId.slice(0, 8)} (unresolved)`,
           parents: [],
           conflictsSnapshot,
+          conflictsSnapshotAfter,
           view: {
             bookmarks: {},
             remoteBookmarks: {},
@@ -12530,8 +12694,24 @@ async function createJJ(options) {
      *   descendants are unaffected (their own immediate parent hasn't been
      *   mutated yet when this function reads it, so the live read is
      *   correct for them). Optional for backward compatibility.
+     * @param {Record<string, any>} [outChangeSnapshot] - If provided,
+     *   populated with `{[descendantId]: fullRecordBeforeRebuild}` for every
+     *   descendant this call actually mutates, BEFORE the mutation —
+     *   matching the `oplog.recordOperation({changeSnapshot})` convention
+     *   used everywhere else in this file (see computeGraphReversal's doc
+     *   comment). Every caller mutates the graph via `graph.updateChange()`
+     *   here without this, so `undo()`/`redo()`/`operations.restore()` had
+     *   nothing to reverse a rebased descendant's content with — the
+     *   descendant rebase itself was simply never recorded in the operation
+     *   (issue #48, R1). Callers should merge this into their own
+     *   `changeSnapshot` before calling `oplog.recordOperation()`.
      */
-    async _rebuildDescendants(ancestorId, stopAtChangeId, originalAncestorSnapshot) {
+    async _rebuildDescendants(
+      ancestorId,
+      stopAtChangeId,
+      originalAncestorSnapshot,
+      outChangeSnapshot
+    ) {
       // Find all descendants of ancestorId
       const allChanges = graph.getAll();
 
@@ -12602,7 +12782,14 @@ async function createJJ(options) {
         // Get parent's ORIGINAL (before absorb) state
         const originalState = originalParentStates.get(descendantId);
         if (!originalState || originalState.parentId !== descendant.parents[0]) {
-          // Parent relationship changed or no original state, just use current parent
+          // Parent relationship changed or no original state, just use current
+          // parent. Not exercised by any current caller (each always builds
+          // `originalParentStates` from a fresh, internally-consistent scan
+          // immediately before this loop runs, with no mutation in between --
+          // see the loop above) -- left as defensive dead code, matching its
+          // pre-existing, already-untested state before issue #48 rather than
+          // adding an `outChangeSnapshot` capture branch here that could never
+          // be exercised either.
           descendant.fileSnapshot = { ...parent.fileSnapshot };
           await graph.updateChange(descendant);
           continue;
@@ -12700,6 +12887,9 @@ async function createJJ(options) {
           newSnapshot[filePath] = resultLines.join('\n');
         }
 
+        if (outChangeSnapshot && !(descendantId in outChangeSnapshot)) {
+          outChangeSnapshot[descendantId] = structuredClone(descendant);
+        }
         descendant.fileSnapshot = newSnapshot;
         await graph.updateChange(descendant);
 
@@ -13723,6 +13913,14 @@ async function createJJ(options) {
         await conflicts.addConflict(conflict);
       }
 
+      // Issue #48 (R2): the AFTER state — see conflicts.resolve()'s
+      // matching `conflictsSnapshotAfter` and computeGraphReversal's doc
+      // comment for why landing exactly on this op needs it.
+      const conflictsSnapshotAfter = {
+        conflicts: Object.fromEntries(conflicts.conflicts),
+        fileConflicts: Object.fromEntries(conflicts.fileConflicts),
+      };
+
       // Record operation with conflicts snapshot
       await oplog.recordOperation({
         timestamp: new Date().toISOString(),
@@ -13736,6 +13934,7 @@ async function createJJ(options) {
           workingCopy: currentChangeId,
         },
         conflictsSnapshot, // Store conflicts state before merge for undo
+        conflictsSnapshotAfter,
       });
 
       return {
@@ -13845,6 +14044,23 @@ async function createJJ(options) {
 
         // Write resolved content to file
         await fs.promises.writeFile(join(dir, conflict.path), resolvedContent, 'utf8');
+        // Keep the working-copy tracker in sync with this out-of-band
+        // write (issue #48, discovered via R2's fix) — otherwise the NEXT
+        // autoSnapshotWorkingCopy() call (status()/read()/etc.) sees a
+        // stale tracked mtime for this file, reports a false "modified",
+        // and records a spurious extra "auto-snapshot working copy"
+        // operation immediately after this one (autoSnapshotWorkingCopy()
+        // now records a real op for that — see its own doc comment).
+        // write()/syncWorkingCopyFiles already do this for every OTHER
+        // direct-to-disk write in this file; this was a gap.
+        {
+          const resolvedStats = await fs.promises.stat(join(dir, conflict.path));
+          await workingCopy.trackFile(conflict.path, {
+            mtime: resolvedStats.mtime,
+            size: resolvedStats.size,
+            mode: resolvedStats.mode,
+          });
+        }
 
         // Mark conflict as resolved
         await conflicts.resolveConflict(args.conflictId, 'manual');
@@ -13864,6 +14080,24 @@ async function createJJ(options) {
           await graph.updateChange(wcChange);
         }
 
+        // Issue #48 (R2): `computeGraphReversal` recovers "the state right
+        // after landingOp" for conflicts by scanning for a LATER op's
+        // "before" snapshot — that only exists if some later op also
+        // touched conflicts. Conflict resolution is usually a one-off
+        // event with nothing later re-touching the ConflictModel at all, so
+        // landing operations.restore()/undo()/redo() exactly on THIS op
+        // found no candidate and left whatever conflict state happened to
+        // already be live completely untouched — restoring the resolved
+        // FILE content correctly (that part goes through the ordinary
+        // changeSnapshot path, which usually does have a later toucher)
+        // while leaving the change's conflict marked unresolved. Recording
+        // the AFTER state directly closes that gap without needing a later
+        // op to exist at all.
+        const conflictsSnapshotAfter = {
+          conflicts: Object.fromEntries(conflicts.conflicts),
+          fileConflicts: Object.fromEntries(conflicts.fileConflicts),
+        };
+
         await oplog.recordOperation({
           timestamp: new Date().toISOString(),
           user: await getUserOplogInfo(),
@@ -13871,6 +14105,7 @@ async function createJJ(options) {
           parents: [],
           changeSnapshot,
           conflictsSnapshot: conflictsSnapshotBefore,
+          conflictsSnapshotAfter,
           view: {
             bookmarks: {},
             remoteBookmarks: {},
@@ -13917,7 +14152,16 @@ async function createJJ(options) {
             const resolvedContent = _resolveWithStrategy(conflict, args.strategy);
 
             // Write resolved content
-            await fs.promises.writeFile(join(dir, conflict.path), resolvedContent, 'utf8');
+            const resolvedPath = join(dir, conflict.path);
+            await fs.promises.writeFile(resolvedPath, resolvedContent, 'utf8');
+            // Keep the working-copy tracker in sync — see resolve()'s
+            // matching comment (issue #48).
+            const resolvedStats = await fs.promises.stat(resolvedPath);
+            await workingCopy.trackFile(conflict.path, {
+              mtime: resolvedStats.mtime,
+              size: resolvedStats.size,
+              mode: resolvedStats.mode,
+            });
 
             // Mark as resolved
             await conflicts.resolveConflict(conflict.conflictId, args.strategy);