Import report

Every automatic conversion produces import-report.json and a readable import-report.md. Each item cites source evidence and has one disposition:

• exact: preserved without a material change;
• converted: mapped to a named native SnabbSajt feature;
• merged: combined with another page or section;
• redirect: an old URL receives a proposed target;
• skipped or unsafe: intentionally left inert, with the reason;
• missing or manual: source facts or operator work are required;
• ai_proposed: an optional evidence-cited suggestion that still needs human approval.

ready means the deterministic report found no unresolved review item. review_required means you must inspect and resolve findings. blocked means known content loss or an input safety limit prevents normal approval.

A review item is one whose disposition is manual, missing, unsafe or ai_proposed, the four the adapter could not decide on its own. Resolving one means writing a resolution onto it:

{
  "status": "accepted",
  "note": "Reviewed and intentionally omitted",
  "resolvedAt": "2026-07-14T10:00:00.000Z"
}

accepted keeps the adapter's outcome (including "this was correctly dropped"); rejected says the outcome is wrong. Validation enforces both directions: a report cannot call itself ready while any review item is unresolved, and an item the adapter already decided for itself (exact, converted, merged, skipped, redirect) cannot carry a resolution at all, so a report can never look reviewed while the items that needed a person went untouched.

Approval is explicit and provenance-bound:

snabbsajt site import approve ./converted --yes

The CLI verifies that site.json and the original deterministic report have not drifted unexpectedly. A blocked import cannot be approved. Use site pack --review-draft only to share evidence for review; that archive has no root site.json and cannot be imported as a normal site.

Merge outcomes

A merge import (into an existing site via mergeIntoWebsiteId) additionally returns one outcome per externalKey:

• added: the key did not exist and its page or section was inserted;
• updated: the key matched, and every field your push changed was applied;
• unchanged: the incoming content is identical to what is already there;
• merged: the key matched, both sides had changed it, and the merge went field by field. Your push landed on every field the owner did not type in, and the fields you both changed were kept as the owner wrote them;
• conflict: the section carries no per-field record from an earlier push, so the older whole-section rule applied and the section was skipped. Pass the key in forceKeys to overwrite it.

A merged or updated outcome carries fields:

{
  "externalKey": "home/hero",
  "action": "merged",
  "fields": {
    "applied": ["subheadline"],
    "kept": [
      {
        "path": "headline",
        "app": "Vi bygger tak i Stockholm",
        "push": "Takläggning i Stockholm"
      }
    ]
  }
}

applied is what your push changed. kept is the honest half: the field, the owner's words, and yours. Nothing there was lost, and nothing was decided for you. To take your version of one field, pass "home/hero#headline" in forceKeys; to take your whole section, pass "home/hero".

A kept field is reported on every later push until it is resolved, either by forcing it or by bringing your repo in line with what the owner wrote. That is deliberate: a disagreement that stops being mentioned is a repo quietly drifting away from the live site.

Lists and pictures count as one field each. A list cannot be merged item by item without mis-reading a reorder as an edit, and splitting a picture would leave the owner's alt text describing your new image.

A merge never deletes anything and never touches site settings, theme, or fonts. A restore point is taken before the first write, so a bad merge can be rolled back from version history.