@helping-ai-workflow/md2doc 3.5.0 → 3.6.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -909,9 +909,44 @@ function diffMembers(ctx, path, was, now, skipKey, edits) {
909
909
  const r = diffValue(ctx, path.concat([key]), was[key], now[key], edits);
910
910
  if (r.ok !== true) return r;
911
911
  }
912
+ // v3.6.0 Task 13 fix round 1 (Critical 1): every new key on THIS object
913
+ // goes into ONE edit, not one `insert` per key.
914
+ //
915
+ // `toPatch()` (this file, `store.toPatch`) always diffs the WHOLE session
916
+ // against the document as it stood when the editor opened — not
917
+ // incrementally, gesture by gesture — so two new sibling fields set at any
918
+ // two points in the same session (the Lane panel's period then phase; two
919
+ // of the six ruler fields) both show up as "new" here in the SAME call.
920
+ // The old code pushed one independent `{op: 'insert', path: […key]}` per
921
+ // key, and `wave-codec.js`'s resolver turns EVERY one of those into a
922
+ // patch anchored at the object's same last EXISTING member — because
923
+ // neither edit can see the other, both compute the identical insertion
924
+ // point, and `patchSource`'s "two edits land at the same place" guard
925
+ // (which exists for exactly this ambiguity) refused the batch. Every
926
+ // session that set two new fields on one object failed, always, not
927
+ // intermittently.
928
+ //
929
+ // Folding them into one `insert-members` edit — resolved by
930
+ // `wave-codec.js`'s `resolveInsertMembers` — gives the object ONE new
931
+ // anchor for however many new keys it picked up this session. Key order
932
+ // inside it is `Object.keys(now)` order (insertion order for a plain
933
+ // object, so it matches the order the fields were actually set in); it
934
+ // does not have to be THE order, because `toPatch()`'s own read-back
935
+ // check just below in this file verifies the combined edit reproduces the
936
+ // exact document regardless of key order (`sameValue` does not compare
937
+ // key order either).
938
+ const newKeys = [];
912
939
  for (const key of Object.keys(now)) {
913
940
  if (key === skipKey) continue;
914
- if (!has(was, key)) edits.push({ op: 'insert', path: path.concat([key]), value: now[key] });
941
+ if (!has(was, key)) newKeys.push(key);
942
+ }
943
+ if (newKeys.length === 1) {
944
+ edits.push({ op: 'insert', path: path.concat([newKeys[0]]), value: now[newKeys[0]] });
945
+ } else if (newKeys.length > 1) {
946
+ edits.push({
947
+ op: 'insert-members', path: path,
948
+ entries: newKeys.map(function (key) { return [key, now[key]]; }),
949
+ });
915
950
  }
916
951
  return OK;
917
952
  }