| name | conflict-resolution |
| description | Resolve the conflicts a document ingest flagged — where a re-ingested document contradicts content the wiki already holds. Walk the SME through each conflict in the chat, document version versus wiki version, apply their decision, and clear the resolved conflicts. Use this whenever a process has ingest conflicts to work through, or the user asks to resolve conflicts. |
Conflict Resolution
You resolve the conflicts a document-ingest flagged — the places where a
re-ingested document contradicted content already in the wiki. document-ingest
never overwrites on a conflict; it records each one and leaves the wiki element
untouched. You walk the SME through those conflicts and apply their decision.
You are invoked with a process <slug>. This is interactive — the SME is
present and decides every conflict; you never resolve one yourself.
Step 1 — Read the conflicts
Read the ingest field in the process JSON wiki/processes/<slug>.json. Its conflicts array holds each
flagged conflict: the element id, the field (a block heading or a
frontmatter field), what the document said (documentSays) and what the wiki
holds (wikiSays).
If the array is empty, reply with exactly:
No conflicts to resolve for this process — nothing was contradicted on the
last ingest.
and stop. Otherwise tell the SME how many conflicts there are, and begin.
Step 2 — Resolve each conflict — D / W / E
Take the conflicts in order. For each, present it plainly:
Conflict {n} of {total} — {element id} · {field}
- The document says: {documentSays}
- The wiki says: {wikiSays}
[D] Take the document version · [W] Keep the wiki version ·
[E] Edit — write a merged version
- [W] — keep the wiki as it is. Nothing is written.
- [D] — the document wins. Apply the document's version with the
updateElement tool — it changes only the conflicted part and leaves the rest
of the element byte-identical, so you never re-type the whole element:
- a block conflict —
use the updateElement({ id, patch }) tool (where patch specifies the block heading and new content)
- a frontmatter field —
use the updateElement({ id, patch }) tool (where patch specifies the field key and new value, or a list of IDs for relations)
- [E] — neither is right alone. Work the merged value out with the SME,
then apply it with the
updateElement tool exactly as in [D].
Apply each decision before moving to the next conflict — never batch. After a
[D] or [E] write, use the checkConformance({ elementId }) tool and fix any flag.
Step 3 — Clear the resolved conflicts
When every conflict has been decided, use the clearConflicts() tool — it empties the conflicts
array in the process JSON's ingest field so the triage screen no longer flags them.
Step 4 — Report
Report with the canonical template:
Conflict resolution complete — **{process}**:
- **Document version taken:** {n}
- **Wiki version kept:** {n}
- **Merged:** {n}
The conflicts are cleared. Review any changed elements on the cards.
Substitute the {process} and {n} counts. Reproduce every other character exactly; this is the single source of truth, never write the report from memory.
Scope
You resolve the conflicts in the process JSON's ingest field and nothing else. You change only
the conflicted field or block of an element, never the rest of it. Everything
you write stays status: draft — the SME approves it in the app. You never
invent a resolution; the SME decides every conflict.
