Per the DIS-080 ruling: on a weave conflict, patch (and get's weave leaf) writes the RGA live reading of the merged weave — both sides' insertions in weave order, no <<<</||||/>>>> fences. The file stays tokenizable, diffable and re-weavable across multiple patch runs. Conflict signalling moves entirely to the durable con <path> row (already appended, patch.js:467-471) and the non-zero PATCHCONFLICT exit (stays, patch.js:482).
wm.merged(...) renders fences (patch.js:199-205, get.js weave leaf ~1061-1096); conflict.hasConflictMarker detects them post-hoc (patch.js:213).con rows; regions recomputed at render time, not stored).patch and get both use it; con row append and mtime band unchanged; PATCHCONFLICT non-zero exit on any conflict unchanged; get keeps its non-fatal warn.hasConflictMarker drops out of the merge path (post's gate goes row-based in POST-035).test/patch/conflict, same-anchor-conflict, dirty-overlap, test/status/conflict) need markerless goldens; PATCH_EXPECT=conflict keeps requiring non-zero exit.WEAVEAlive semantics over the union weave — every token whose RM bit is clear, in weave order, which is dog's symmetric RGA order (commit-id tie-break). Both sides' insertions at one anchor read out back to back, ours/theirs by hash order, never by caller side.weave.mergedLive(wm, groupIds) -> { bytes, spans } mirrors the C WEAVEEmitMerged run walk with the fences replaced by weave order: a run of non-shared tokens CONFLICTS iff two membership masks are disjoint; the byte-equality collapse (re-absorbed cherry/foster content) is kept, so NON-conflicting output is byte-identical to the old fenced render — only conflicted runs change.wm.commits[inserter] against the per-side hashlet sets (index 0 = spine = shared), the JS twin of WEAVEScope+weave_emit_membership — deterministic across replicas, no clock/side input.spans.length > 0; con rows, the mtime band (pat/mrg/cnf) and the PATCHCONFLICT non-zero exit are untouched.conRecorded), no marker scan.test/post/patch-absorb FAILS (the ONLY red in ctest, 315/316): post's marker pre-scan (post.js:888) no longer sees a conflict, so a conflicted absorb commits instead of refusing. That gate is POST-035 (out of scope here) — patch-absorb goes green when the row-based gate lands.wtHasMarker (STATUS-005 con liveness) is now DEAD for our output; con still shows because the patch/get mtime band spells cnf/con. Row-based liveness is STATUS-017.///be/#5c0d5c21 (GET-056b matrix landed): trunk weave3 STORED its token-level <<<</||||/>>>> render into verbs/get/get.js + shared/weave.js (con rows) — the exact DIS-080 violation this ticket removes; markers glue MID-LINE so get.js is not valid JS, and the wt's own jab now throws SyntaxError: Unexpected token '<<' loading the get verb (get is bricked IN this wt until the file is resolved by hand or from outside).shared/weave.js — GET-056b relocated the function, so the get.js side of ours mostly dissolves into a small wm.merged → mergedLive swap at be/shared/weave.js:183.shared/weave.js exports region — both sides INSERTED different lines at the same anchor (trunk's weave3 export vs ours' mergedLive export); disjoint same-anchor adds should coexist, not conflict. get.js's regions are real (ours edits weave3 in place, theirs deletes it wholesale).hunk.render: out full).PATCH-025: markerless RGA conflict bytes//PATCH-025: shared/weave.js (mergedLive), verbs/patch/patch.js, verbs/get/get.js.<<<<<<<<<Y||||X>>>>|||||Z>>>>>, now folds to YXZ).grep '<<<<' || fail became if grep '<<<<' then fail + both-sides greps. Plus a stale-comment fix in test/get/detached-recover.weave3, GREEN with mergedLive.543269d6): the five lost regolds (get/conf-state, get/confdrop, get/dirty, post/conf-state, status/conflict) were re-applied identically, re-verified red→green, and all 17 files (3 code + 14 test) re-staged. ctest -j16 = 315/316 on the new base; be-js-unit-wtlog_con (trunk-provided) passes.weave3's theirs==base ⇒ keep ours arm is byte-identical before and after PATCH-025, and the removed POST-032 skip only ever fired for con-row paths (none in this wt) — so the content clobber is not this ticket's edit.