Authoring
Conflict Resolution Assistant
If the widget changed on the instance between your pull and push, a guided 3-way merge opens instead of overwriting.
The Assistant performs a 3-way merge using three versions of each field: your local edits, the current server version, and the common ancestor captured at pull time (stored in a hidden .baseline/ inside the widget folder).
How each field is classified
Every field (template.html, styles.scss, client.js, server.js, …) is classified:
| State | Meaning |
|---|---|
| Unchanged | Local and server are identical — nothing to do |
| Auto-resolved | Only one side changed, or both changed different lines → merged automatically |
| Needs resolution | Both sides changed the same lines → you decide |
For a field that needs resolution, Resolve opens the merged result with git-style conflict markers, where VS Code shows its native inline Accept Current Change / Accept Incoming Change / Accept Both Changes buttons. Quick Use Mine / Use Theirs buttons take a whole field at once.
- The working files are only written on Apply — nothing is touched while you review, so Cancel leaves everything as it was.
- Apply is blocked while any
<<<<<<<markers remain unresolved. - Every resolution is appended to
.sn-widget-kit-conflict-audit.jsonl(timestamp, widget, per-field choices, whether it was pushed) for auditing.
First conflict on older widgets
Widgets pulled before this version have no
.baseline/ yet; on their first conflict the merge falls back to a whole-field conflict you resolve manually. The baseline is written on every pull and after each resolved push, so subsequent conflicts are full 3-way.Don't edit .baseline/ by hand
The
.baseline/ folders are an internal merge artifact. They are hidden from the VS Code Explorer (via files.exclude) and kept out of git (via .gitignore, when the project is a git repo).