merge-artifacts
Merge Artifacts
Reconcile several competing candidate drafts of ONE artifact into a single coherent result. The candidates are parallel attempts at the same subject — the same spec drafted by different models, two attempts at the same proposal, and so on. You compare them systematically, fold everything each one contributes, settle what is objectively resolvable and queue every genuine divergence for a human, and write one canonical artifact at its thread root. You read the candidates but never edit them.
This is a bake-off collapse, not a way to keep distinct subjects. If the inputs are genuinely different subjects the user wants to keep separate (an API spec and a CLI spec), this is not a merge — say so, write nothing, and end with Outcome: REFUSED — inputs are distinct subjects, not competing drafts of one artifact, rather than flattening them into one artifact.
Inputs
The caller supplies the candidate paths explicitly. The candidates may live anywhere — inside or outside the thread, any directory. There is no standard draft folder and you never scan the filesystem to discover candidates on your own; you merge exactly the paths you are given. If a reference is vague ("the drafts", "the two attempts") and more than one plausible set exists, that is a preflight failure: refuse, name the vague reference and ask for the exact candidate paths, write nothing, and end with Outcome: REFUSED — <the ambiguity and how to re-invoke> rather than picking by recency or sort order — that would silently choose which drafts the user reconciles.
You read every candidate READ-ONLY: you do not edit, rewrite, reformat, or add frontmatter to any candidate. Read each one end-to-end before composing anything.
Determine the target artifact type:
- Same-type default — when every candidate is a draft of the same type, the merge produces that type. Three spec drafts yield one spec; two proposal drafts yield one proposal. No target-type statement is needed.
- Cross-type — when the candidates are of different types and the user wants them reconciled into a target of yet another type (e.g. a proposal draft plus a discussion together yielding a spec), the user MUST state the target type explicitly. If mixed-type candidates arrive with no stated target, do not infer a cross-type target from the inputs alone — that is a preflight failure: refuse, naming that a mixed-type merge needs an explicit target type, write nothing, and end with
Outcome: REFUSED — mixed-type candidates with no stated target; re-invoke with the target type.