diff --git a/docs/qualification/v0-2-0/01-created-saved.md b/docs/qualification/v0-2-0/01-created-saved.md
new file mode 100644
index 0000000..4861834
--- /dev/null
+++ b/docs/qualification/v0-2-0/01-created-saved.md
@@ -0,0 +1,33 @@
+Risk is manageable. The release decision is to retain a backup supplier.
+
+
+```terraphim-alternatives
+{
+  "version": 1,
+  "spans": [
+    {
+      "id": "s1",
+      "kind": "word",
+      "anchor": {
+        "start": 0,
+        "end": 4,
+        "text": "Risk",
+        "before": "",
+        "after": " is manageable. The release "
+      },
+      "active": 0,
+      "alts": [
+        {
+          "text": "Risk",
+          "source": "original"
+        },
+        {
+          "text": "Concern",
+          "source": "human"
+        }
+      ]
+    }
+  ],
+  "ghosts": []
+}
+```
diff --git a/docs/qualification/v0-2-0/02-undo-saved.md b/docs/qualification/v0-2-0/02-undo-saved.md
new file mode 100644
index 0000000..bb5f26c
--- /dev/null
+++ b/docs/qualification/v0-2-0/02-undo-saved.md
@@ -0,0 +1 @@
+Risk is manageable. The release decision is to retain a backup supplier.
diff --git a/docs/qualification/v0-2-0/03-redo-reopened.md b/docs/qualification/v0-2-0/03-redo-reopened.md
new file mode 100644
index 0000000..4861834
--- /dev/null
+++ b/docs/qualification/v0-2-0/03-redo-reopened.md
@@ -0,0 +1,33 @@
+Risk is manageable. The release decision is to retain a backup supplier.
+
+
+```terraphim-alternatives
+{
+  "version": 1,
+  "spans": [
+    {
+      "id": "s1",
+      "kind": "word",
+      "anchor": {
+        "start": 0,
+        "end": 4,
+        "text": "Risk",
+        "before": "",
+        "after": " is manageable. The release "
+      },
+      "active": 0,
+      "alts": [
+        {
+          "text": "Risk",
+          "source": "original"
+        },
+        {
+          "text": "Concern",
+          "source": "human"
+        }
+      ]
+    }
+  ],
+  "ghosts": []
+}
+```
diff --git a/docs/qualification/v0-2-0/04-swap-saved.md b/docs/qualification/v0-2-0/04-swap-saved.md
new file mode 100644
index 0000000..0791d94
--- /dev/null
+++ b/docs/qualification/v0-2-0/04-swap-saved.md
@@ -0,0 +1,33 @@
+Concern is manageable. The release decision is to retain a backup supplier.
+
+
+```terraphim-alternatives
+{
+  "version": 1,
+  "spans": [
+    {
+      "id": "s1",
+      "kind": "word",
+      "anchor": {
+        "start": 0,
+        "end": 7,
+        "text": "Concern",
+        "before": "",
+        "after": " is manageable. The release "
+      },
+      "active": 1,
+      "alts": [
+        {
+          "text": "Risk",
+          "source": "original"
+        },
+        {
+          "text": "Concern",
+          "source": "human"
+        }
+      ]
+    }
+  ],
+  "ghosts": []
+}
+```
diff --git a/docs/qualification/v0-2-0/05-exported-graph.json b/docs/qualification/v0-2-0/05-exported-graph.json
new file mode 100644
index 0000000..0d2fdd0
--- /dev/null
+++ b/docs/qualification/v0-2-0/05-exported-graph.json
@@ -0,0 +1,17 @@
+{
+  "name": "Document alternatives",
+  "data": {
+    "risk": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    },
+    "concern": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    }
+  }
+}
diff --git a/docs/qualification/v0-2-0/06-repeated-export.json b/docs/qualification/v0-2-0/06-repeated-export.json
new file mode 100644
index 0000000..4053867
--- /dev/null
+++ b/docs/qualification/v0-2-0/06-repeated-export.json
@@ -0,0 +1,17 @@
+{
+  "name": "Document alternatives",
+  "data": {
+    "concern": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    },
+    "risk": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    }
+  }
+}
diff --git a/docs/qualification/v0-2-0/07-grep-before-sharing.json b/docs/qualification/v0-2-0/07-grep-before-sharing.json
new file mode 100644
index 0000000..a036888
--- /dev/null
+++ b/docs/qualification/v0-2-0/07-grep-before-sharing.json
@@ -0,0 +1,13 @@
+{
+  "chunks": [],
+  "answer": null,
+  "concepts": [],
+  "sufficiency": "RlmInsufficient",
+  "sufficiency_explanation": "No chunks or knowledge-graph concepts matched the query; there is nothing to synthesise an answer from.",
+  "stats": {
+    "search_latency_ms": 3,
+    "rlm_latency_ms": null,
+    "chunks_returned": 0,
+    "kg_hits": 0
+  }
+}
diff --git a/docs/qualification/v0-2-0/08-grep-with-authored-synonym.json b/docs/qualification/v0-2-0/08-grep-with-authored-synonym.json
new file mode 100644
index 0000000..7712b45
--- /dev/null
+++ b/docs/qualification/v0-2-0/08-grep-with-authored-synonym.json
@@ -0,0 +1,35 @@
+{
+  "chunks": [
+    {
+      "content": "Risk is manageable. The release decision is to retain a backup supplier.",
+      "source": "brief.md",
+      "line_start": 1,
+      "line_end": 1,
+      "relevance_score": 2.0,
+      "haystack": "code"
+    }
+  ],
+  "answer": null,
+  "concepts": [
+    {
+      "id": 0,
+      "name": "concern",
+      "display_value": null,
+      "score": 1.0
+    },
+    {
+      "id": 0,
+      "name": "risk",
+      "display_value": null,
+      "score": 1.0
+    }
+  ],
+  "sufficiency": "RlmInsufficient",
+  "sufficiency_explanation": "Only 1 chunk(s) and 2 KG concept(s) were retrieved; the minimum for a meaningful answer is 3 chunks, and coverage was 1.00. Too little evidence to synthesise -- try broadening the query or the searched paths.",
+  "stats": {
+    "search_latency_ms": 2,
+    "rlm_latency_ms": null,
+    "chunks_returned": 1,
+    "kg_hits": 2
+  }
+}
diff --git a/docs/qualification/v0-2-0/09-hazard-pending-source.md b/docs/qualification/v0-2-0/09-hazard-pending-source.md
new file mode 100644
index 0000000..26e2014
--- /dev/null
+++ b/docs/qualification/v0-2-0/09-hazard-pending-source.md
@@ -0,0 +1,37 @@
+Concern is manageable. The release decision is to retain a backup supplier.
+
+
+```terraphim-alternatives
+{
+  "version": 1,
+  "spans": [
+    {
+      "id": "s1",
+      "kind": "word",
+      "anchor": {
+        "start": 0,
+        "end": 7,
+        "text": "Concern",
+        "before": "",
+        "after": " is manageable. The release "
+      },
+      "active": 1,
+      "alts": [
+        {
+          "text": "Risk",
+          "source": "original"
+        },
+        {
+          "text": "Concern",
+          "source": "human"
+        },
+        {
+          "text": "Hazard",
+          "source": "human"
+        }
+      ]
+    }
+  ],
+  "ghosts": []
+}
+```
diff --git a/docs/qualification/v0-2-0/10-dirty-graph-disk-before.json b/docs/qualification/v0-2-0/10-dirty-graph-disk-before.json
new file mode 100644
index 0000000..4053867
--- /dev/null
+++ b/docs/qualification/v0-2-0/10-dirty-graph-disk-before.json
@@ -0,0 +1,17 @@
+{
+  "name": "Document alternatives",
+  "data": {
+    "concern": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    },
+    "risk": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    }
+  }
+}
diff --git a/docs/qualification/v0-2-0/11-dirty-graph-disk-after-refusal.json b/docs/qualification/v0-2-0/11-dirty-graph-disk-after-refusal.json
new file mode 100644
index 0000000..4053867
--- /dev/null
+++ b/docs/qualification/v0-2-0/11-dirty-graph-disk-after-refusal.json
@@ -0,0 +1,17 @@
+{
+  "name": "Document alternatives",
+  "data": {
+    "concern": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    },
+    "risk": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    }
+  }
+}
diff --git a/docs/qualification/v0-2-0/12-preserved-interior-saved.json b/docs/qualification/v0-2-0/12-preserved-interior-saved.json
new file mode 100644
index 0000000..03b4a8d
--- /dev/null
+++ b/docs/qualification/v0-2-0/12-preserved-interior-saved.json
@@ -0,0 +1,17 @@
+{
+    "name": "UNSAVED INTERIOR RC7",
+  "data": {
+    "concern": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    },
+    "risk": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    }
+  }
+}
diff --git a/docs/qualification/v0-2-0/13-export-after-save-with-hazard.json b/docs/qualification/v0-2-0/13-export-after-save-with-hazard.json
new file mode 100644
index 0000000..5d7e591
--- /dev/null
+++ b/docs/qualification/v0-2-0/13-export-after-save-with-hazard.json
@@ -0,0 +1,23 @@
+{
+  "name": "Document alternatives",
+  "data": {
+    "concern": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    },
+    "risk": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    },
+    "hazard": {
+      "id": 1,
+      "nterm": "risk",
+      "display_value": "Risk",
+      "pinned": false
+    }
+  }
+}
diff --git a/docs/qualification/v0-2-0/14-trim-done-saved.md b/docs/qualification/v0-2-0/14-trim-done-saved.md
new file mode 100644
index 0000000..ecb44de
--- /dev/null
+++ b/docs/qualification/v0-2-0/14-trim-done-saved.md
@@ -0,0 +1,161 @@
+# Harbour project brief
+
+The risk is a delayed launch.
+
+# Why our release notes are too long
+
+I think most of our release notes are basically longer than they need to be. Readers open them to answer one question, which is whether the update changes anything they rely on, and they leave as soon as they have the answer. Every extra paragraph makes that answer harder to find.
+
+The draft for the last release is a good example. It opened with three sentences about the history of the project (which nobody had asked about) before it reached the first change. It then described the new search index in detail, really quite a lot of detail, although only a handful of users ever configure it by hand. The breaking change to the configuration file, the one thing that could actually stop a deployment, appeared near the end, in the second half of a long sentence.
+
+Perhaps the habit comes from how the notes are written. Each engineer adds a paragraph for their own work, usually at the end of a long day, and nobody reads the whole document from the top before it ships. The result is a list of updates in the order they were merged rather than in the order that matters to a reader. It is honestly not anyone's fault, and it is fairly easy to fix.
+
+We could start with a simple rule. The first paragraph should say, in plain words, what a reader has to do after upgrading, and it should say nothing else. If the answer is "nothing", the paragraph can simply say so — readers will be grateful for the time it saves them. Everything that follows is reference material, and reference material can be as detailed as it needs to be, because people only read the parts they search for.
+
+A second rule would help as well. Every change should be described once, in one place, with one sentence of context at most. At the moment the same change is often mentioned in the summary, again in the list of fixes and again in the upgrade guide, each time with slightly different wording, which makes readers wonder whether there are really three separate changes.
+
+It would also be worth keeping a short glossary. Terms such as "haystack", "role" and "thesaurus" are obvious to the people who build the system, but they are not obvious to someone who installed it last week. A glossary of a dozen entries, linked from the notes, would answer most of the questions that currently arrive in the support channel.
+
+None of this needs new tooling. It needs one person to read each draft from start to finish, ask what the reader must do, and delete the rest without too much regret. In my experience the notes get shorter, the questions get fewer, and the people who write the notes end up spending less time on them, not more.
+
+```terraphim-alternatives
+{
+  "version": 1,
+  "spans": [
+    {
+      "id": "s1",
+      "kind": "word",
+      "anchor": {
+        "start": 29,
+        "end": 33,
+        "text": "risk",
+        "before": "# Harbour project brief\n\nThe ",
+        "after": " is a delayed launch.\n\n# Why our"
+      },
+      "active": 0,
+      "alts": [
+        {
+          "text": "risk",
+          "source": "original"
+        },
+        {
+          "text": "concern",
+          "source": "human"
+        }
+      ]
+    }
+  ],
+  "ghosts": [
+    {
+      "id": "trim-ghost-1",
+      "anchor": {
+        "start": 94,
+        "end": 102,
+        "text": "I think ",
+        "before": "our release notes are too long\n\n",
+        "after": "most of our release notes are "
+      }
+    },
+    {
+      "id": "trim-ghost-2",
+      "anchor": {
+        "start": 131,
+        "end": 141,
+        "text": " basically",
+        "before": " most of our release notes are",
+        "after": " longer than they need to be. "
+      }
+    },
+    {
+      "id": "trim-ghost-3",
+      "anchor": {
+        "start": 211,
+        "end": 270,
+        "text": ", which is whether the update changes anything they rely on",
+        "before": "open them to answer one question",
+        "after": ", and they leave as soon as they"
+      }
+    },
+    {
+      "id": "trim-ghost-4",
+      "anchor": {
+        "start": 319,
+        "end": 375,
+        "text": " Every extra paragraph makes that answer harder to find.",
+        "before": "as soon as they have the answer.",
+        "after": "\n\nThe draft for the last release"
+      }
+    },
+    {
+      "id": "trim-ghost-5",
+      "anchor": {
+        "start": 490,
+        "end": 521,
+        "text": " (which nobody had asked about)",
+        "before": "about the history of the project",
+        "after": " before it reached the first "
+      }
+    },
+    {
+      "id": "trim-ghost-6",
+      "anchor": {
+        "start": 557,
+        "end": 697,
+        "text": " It then described the new search index in detail, really quite a lot of detail, although only a handful of users ever configure it by hand.",
+        "before": " it reached the first change.",
+        "after": " The breaking change to the "
+      }
+    },
+    {
+      "id": "trim-ghost-7",
+      "anchor": {
+        "start": 769,
+        "end": 778,
+        "text": " actually",
+        "before": " file, the one thing that could",
+        "after": " stop a deployment, appeared "
+      }
+    },
+    {
+      "id": "trim-ghost-8",
+      "anchor": {
+        "start": 861,
+        "end": 869,
+        "text": "Perhaps ",
+        "before": " half of a long sentence.\n\n",
+        "after": "the habit comes from how the "
+      }
+    },
+    {
+      "id": "trim-ghost-9",
+      "anchor": {
+        "start": 1180,
+        "end": 1245,
+        "text": " It is honestly not anyone's fault, and it is fairly easy to fix.",
+        "before": " order that matters to a reader.",
+        "after": "\n\nWe could start with a simple "
+      }
+    },
+    {
+      "id": "trim-ghost-10",
+      "anchor": {
+        "start": 1402,
+        "end": 1517,
+        "text": " If the answer is \"nothing\", the paragraph can simply say so — readers will be grateful for the time it saves them.",
+        "before": " and it should say nothing else.",
+        "after": " Everything that follows is "
+      }
+    },
+    {
+      "id": "trim-ghost-11",
+      "anchor": {
+        "start": 1969,
+        "end": 2045,
+        "text": ", which makes readers wonder whether there are really three separate changes",
+        "before": " with slightly different wording",
+        "after": ".\n\nIt would also be worth "
+      }
+    }
+  ]
+}
+```
diff --git a/docs/qualification/v0-2-0/15-post-trim-edit-saved.md b/docs/qualification/v0-2-0/15-post-trim-edit-saved.md
new file mode 100644
index 0000000..a070151
--- /dev/null
+++ b/docs/qualification/v0-2-0/15-post-trim-edit-saved.md
@@ -0,0 +1,161 @@
+UPDATED # Harbour project brief
+
+The risk is a delayed launch.
+
+# Why our release notes are too long
+
+I think most of our release notes are basically longer than they need to be. Readers open them to answer one question, which is whether the update changes anything they rely on, and they leave as soon as they have the answer. Every extra paragraph makes that answer harder to find.
+
+The draft for the last release is a good example. It opened with three sentences about the history of the project (which nobody had asked about) before it reached the first change. It then described the new search index in detail, really quite a lot of detail, although only a handful of users ever configure it by hand. The breaking change to the configuration file, the one thing that could actually stop a deployment, appeared near the end, in the second half of a long sentence.
+
+Perhaps the habit comes from how the notes are written. Each engineer adds a paragraph for their own work, usually at the end of a long day, and nobody reads the whole document from the top before it ships. The result is a list of updates in the order they were merged rather than in the order that matters to a reader. It is honestly not anyone's fault, and it is fairly easy to fix.
+
+We could start with a simple rule. The first paragraph should say, in plain words, what a reader has to do after upgrading, and it should say nothing else. If the answer is "nothing", the paragraph can simply say so — readers will be grateful for the time it saves them. Everything that follows is reference material, and reference material can be as detailed as it needs to be, because people only read the parts they search for.
+
+A second rule would help as well. Every change should be described once, in one place, with one sentence of context at most. At the moment the same change is often mentioned in the summary, again in the list of fixes and again in the upgrade guide, each time with slightly different wording, which makes readers wonder whether there are really three separate changes.
+
+It would also be worth keeping a short glossary. Terms such as "haystack", "role" and "thesaurus" are obvious to the people who build the system, but they are not obvious to someone who installed it last week. A glossary of a dozen entries, linked from the notes, would answer most of the questions that currently arrive in the support channel.
+
+None of this needs new tooling. It needs one person to read each draft from start to finish, ask what the reader must do, and delete the rest without too much regret. In my experience the notes get shorter, the questions get fewer, and the people who write the notes end up spending less time on them, not more.
+
+```terraphim-alternatives
+{
+  "version": 1,
+  "spans": [
+    {
+      "id": "s1",
+      "kind": "word",
+      "anchor": {
+        "start": 37,
+        "end": 41,
+        "text": "risk",
+        "before": " # Harbour project brief\n\nThe ",
+        "after": " is a delayed launch.\n\n# Why our"
+      },
+      "active": 0,
+      "alts": [
+        {
+          "text": "risk",
+          "source": "original"
+        },
+        {
+          "text": "concern",
+          "source": "human"
+        }
+      ]
+    }
+  ],
+  "ghosts": [
+    {
+      "id": "trim-ghost-1",
+      "anchor": {
+        "start": 102,
+        "end": 110,
+        "text": "I think ",
+        "before": "our release notes are too long\n\n",
+        "after": "most of our release notes are "
+      }
+    },
+    {
+      "id": "trim-ghost-2",
+      "anchor": {
+        "start": 139,
+        "end": 149,
+        "text": " basically",
+        "before": " most of our release notes are",
+        "after": " longer than they need to be. "
+      }
+    },
+    {
+      "id": "trim-ghost-3",
+      "anchor": {
+        "start": 219,
+        "end": 278,
+        "text": ", which is whether the update changes anything they rely on",
+        "before": "open them to answer one question",
+        "after": ", and they leave as soon as they"
+      }
+    },
+    {
+      "id": "trim-ghost-4",
+      "anchor": {
+        "start": 327,
+        "end": 383,
+        "text": " Every extra paragraph makes that answer harder to find.",
+        "before": "as soon as they have the answer.",
+        "after": "\n\nThe draft for the last release"
+      }
+    },
+    {
+      "id": "trim-ghost-5",
+      "anchor": {
+        "start": 498,
+        "end": 529,
+        "text": " (which nobody had asked about)",
+        "before": "about the history of the project",
+        "after": " before it reached the first "
+      }
+    },
+    {
+      "id": "trim-ghost-6",
+      "anchor": {
+        "start": 565,
+        "end": 705,
+        "text": " It then described the new search index in detail, really quite a lot of detail, although only a handful of users ever configure it by hand.",
+        "before": " it reached the first change.",
+        "after": " The breaking change to the "
+      }
+    },
+    {
+      "id": "trim-ghost-7",
+      "anchor": {
+        "start": 777,
+        "end": 786,
+        "text": " actually",
+        "before": " file, the one thing that could",
+        "after": " stop a deployment, appeared "
+      }
+    },
+    {
+      "id": "trim-ghost-8",
+      "anchor": {
+        "start": 869,
+        "end": 877,
+        "text": "Perhaps ",
+        "before": " half of a long sentence.\n\n",
+        "after": "the habit comes from how the "
+      }
+    },
+    {
+      "id": "trim-ghost-9",
+      "anchor": {
+        "start": 1188,
+        "end": 1253,
+        "text": " It is honestly not anyone's fault, and it is fairly easy to fix.",
+        "before": " order that matters to a reader.",
+        "after": "\n\nWe could start with a simple "
+      }
+    },
+    {
+      "id": "trim-ghost-10",
+      "anchor": {
+        "start": 1410,
+        "end": 1525,
+        "text": " If the answer is \"nothing\", the paragraph can simply say so — readers will be grateful for the time it saves them.",
+        "before": " and it should say nothing else.",
+        "after": " Everything that follows is "
+      }
+    },
+    {
+      "id": "trim-ghost-11",
+      "anchor": {
+        "start": 1977,
+        "end": 2053,
+        "text": ", which makes readers wonder whether there are really three separate changes",
+        "before": " with slightly different wording",
+        "after": ".\n\nIt would also be worth "
+      }
+    }
+  ]
+}
+```
diff --git a/docs/qualification/v0-2-0/16-clean-export.md b/docs/qualification/v0-2-0/16-clean-export.md
new file mode 100644
index 0000000..5db0250
--- /dev/null
+++ b/docs/qualification/v0-2-0/16-clean-export.md
@@ -0,0 +1,19 @@
+UPDATED # Harbour project brief
+
+The risk is a delayed launch.
+
+# Why our release notes are too long
+
+most of our release notes are longer than they need to be. Readers open them to answer one question, and they leave as soon as they have the answer.
+
+The draft for the last release is a good example. It opened with three sentences about the history of the project before it reached the first change. The breaking change to the configuration file, the one thing that could stop a deployment, appeared near the end, in the second half of a long sentence.
+
+the habit comes from how the notes are written. Each engineer adds a paragraph for their own work, usually at the end of a long day, and nobody reads the whole document from the top before it ships. The result is a list of updates in the order they were merged rather than in the order that matters to a reader.
+
+We could start with a simple rule. The first paragraph should say, in plain words, what a reader has to do after upgrading, and it should say nothing else. Everything that follows is reference material, and reference material can be as detailed as it needs to be, because people only read the parts they search for.
+
+A second rule would help as well. Every change should be described once, in one place, with one sentence of context at most. At the moment the same change is often mentioned in the summary, again in the list of fixes and again in the upgrade guide, each time with slightly different wording.
+
+It would also be worth keeping a short glossary. Terms such as "haystack", "role" and "thesaurus" are obvious to the people who build the system, but they are not obvious to someone who installed it last week. A glossary of a dozen entries, linked from the notes, would answer most of the questions that currently arrive in the support channel.
+
+None of this needs new tooling. It needs one person to read each draft from start to finish, ask what the reader must do, and delete the rest without too much regret. In my experience the notes get shorter, the questions get fewer, and the people who write the notes end up spending less time on them, not more.
diff --git a/docs/qualification/v0-2-0/17-dirty-clean-disk-after-refusal.md b/docs/qualification/v0-2-0/17-dirty-clean-disk-after-refusal.md
new file mode 100644
index 0000000..5db0250
--- /dev/null
+++ b/docs/qualification/v0-2-0/17-dirty-clean-disk-after-refusal.md
@@ -0,0 +1,19 @@
+UPDATED # Harbour project brief
+
+The risk is a delayed launch.
+
+# Why our release notes are too long
+
+most of our release notes are longer than they need to be. Readers open them to answer one question, and they leave as soon as they have the answer.
+
+The draft for the last release is a good example. It opened with three sentences about the history of the project before it reached the first change. The breaking change to the configuration file, the one thing that could stop a deployment, appeared near the end, in the second half of a long sentence.
+
+the habit comes from how the notes are written. Each engineer adds a paragraph for their own work, usually at the end of a long day, and nobody reads the whole document from the top before it ships. The result is a list of updates in the order they were merged rather than in the order that matters to a reader.
+
+We could start with a simple rule. The first paragraph should say, in plain words, what a reader has to do after upgrading, and it should say nothing else. Everything that follows is reference material, and reference material can be as detailed as it needs to be, because people only read the parts they search for.
+
+A second rule would help as well. Every change should be described once, in one place, with one sentence of context at most. At the moment the same change is often mentioned in the summary, again in the list of fixes and again in the upgrade guide, each time with slightly different wording.
+
+It would also be worth keeping a short glossary. Terms such as "haystack", "role" and "thesaurus" are obvious to the people who build the system, but they are not obvious to someone who installed it last week. A glossary of a dozen entries, linked from the notes, would answer most of the questions that currently arrive in the support channel.
+
+None of this needs new tooling. It needs one person to read each draft from start to finish, ask what the reader must do, and delete the rest without too much regret. In my experience the notes get shorter, the questions get fewer, and the people who write the notes end up spending less time on them, not more.
diff --git a/docs/qualification/v0-2-0/18-preserved-clean-edit-saved.md b/docs/qualification/v0-2-0/18-preserved-clean-edit-saved.md
new file mode 100644
index 0000000..7a9c8ba
--- /dev/null
+++ b/docs/qualification/v0-2-0/18-preserved-clean-edit-saved.md
@@ -0,0 +1,20 @@
+UNSAVED CLEAN DESTINATION
+UPDATED # Harbour project brief
+
+The risk is a delayed launch.
+
+# Why our release notes are too long
+
+most of our release notes are longer than they need to be. Readers open them to answer one question, and they leave as soon as they have the answer.
+
+The draft for the last release is a good example. It opened with three sentences about the history of the project before it reached the first change. The breaking change to the configuration file, the one thing that could stop a deployment, appeared near the end, in the second half of a long sentence.
+
+the habit comes from how the notes are written. Each engineer adds a paragraph for their own work, usually at the end of a long day, and nobody reads the whole document from the top before it ships. The result is a list of updates in the order they were merged rather than in the order that matters to a reader.
+
+We could start with a simple rule. The first paragraph should say, in plain words, what a reader has to do after upgrading, and it should say nothing else. Everything that follows is reference material, and reference material can be as detailed as it needs to be, because people only read the parts they search for.
+
+A second rule would help as well. Every change should be described once, in one place, with one sentence of context at most. At the moment the same change is often mentioned in the summary, again in the list of fixes and again in the upgrade guide, each time with slightly different wording.
+
+It would also be worth keeping a short glossary. Terms such as "haystack", "role" and "thesaurus" are obvious to the people who build the system, but they are not obvious to someone who installed it last week. A glossary of a dozen entries, linked from the notes, would answer most of the questions that currently arrive in the support channel.
+
+None of this needs new tooling. It needs one person to read each draft from start to finish, ask what the reader must do, and delete the rest without too much regret. In my experience the notes get shorter, the questions get fewer, and the people who write the notes end up spending less time on them, not more.
diff --git a/docs/qualification/v0-2-0/README.md b/docs/qualification/v0-2-0/README.md
new file mode 100644
index 0000000..197c581
--- /dev/null
+++ b/docs/qualification/v0-2-0/README.md
@@ -0,0 +1,9 @@
+# Stock-Zed source qualification, 14 October 2026
+
+This receipt records the eight functional checks run against catalog source `b75b475adebe42604ac9ba86023b884c7049bc58` in stock Zed 1.23.3. The fresh profile automatically downloaded the public RC7 LSP. The development-install WASM hash is separate from any CI-built release WASM.
+
+The numbered files are actual saved outputs. Outputs 01–04 prove authoring, undo/redo, reopening and swapping. Outputs 05–08 prove repeated synonym export and released-grep retrieval. Outputs 09–13 prove that a new Hazard synonym was pending while an unsaved interior JSON change was refused and preserved; saving the edit permitted the next export. Outputs 14–18 prove Trim persistence, anchor movement, clean export and dirty Markdown destination protection. The preauthored Trim fixture is input, not newly generated authoring output.
+
+The functional checks passed. Native CUA screenshots showed the refusal and preserved buffers, but native Screenshot and Preview capture attempts did not produce a durable image. No downloadable screenshot is claimed. The receipt records this visual-evidence limitation instead of substituting an image or headless test.
+
+This evidence covers a source development installation. A separate receipt must verify the actual downloaded compiled package after release. Official Zed catalog acceptance and installation remain separate. It does not certify all 41 browser-editor requirements or the Zed application fork.
diff --git a/docs/qualification/v0-2-0/source-qualification.json b/docs/qualification/v0-2-0/source-qualification.json
new file mode 100644
index 0000000..9db8180
--- /dev/null
+++ b/docs/qualification/v0-2-0/source-qualification.json
@@ -0,0 +1,185 @@
+{
+  "schema": 1,
+  "status": "PASS",
+  "scope": "stock-zed-source",
+  "qualificationMeaning": "The eight listed functional saved-output checks passed on stock Zed. The visual evidence limitation below remains explicit. This is source-dev installation, not a released compiled extension package or registry install.",
+  "qualifiedCommit": "b75b475adebe42604ac9ba86023b884c7049bc58",
+  "extensionId": "terraphim-lsp",
+  "extensionPath": "catalog/terraphim-lsp",
+  "version": "0.2.0",
+  "host": {
+    "application": "Zed",
+    "version": "1.23.3",
+    "platform": "macOS ARM64"
+  },
+  "sourceInstallWasm": {
+    "sha256": "a062ba4648a91723db1bd7712dab48cd27546c9413ac6d238a812a8d9020e95c",
+    "bytes": 562871
+  },
+  "server": {
+    "releaseTag": "terraphim_lsp-v1.22.0-rc.7",
+    "source": "4fb62d337c306a9105c5e872f3400f3052a2caef",
+    "sha256": "ed60697248dfbef1d3b731e5f758fd7f02c00c74b3da8581df11dd78fa2e32cd",
+    "bytes": 13497968
+  },
+  "checks": {
+    "defaultProvisioning": "PASS",
+    "cacheRestart": "PASS",
+    "createApplySaveUndoRedoReopen": "PASS",
+    "synonymGraphExportTwice": "PASS",
+    "dirtyJsonRefusal": "PASS",
+    "trimDoneAnchorShift": "PASS",
+    "cleanExportDirtyRefusal": "PASS",
+    "releasedGrepSharedSynonym": "PASS"
+  },
+  "savedOutputs": [
+    {
+      "name": "01-created-saved.md",
+      "sha256": "fa6ab1275ca14df7920b2e05edd9a421e322af5c400bbeb5aca57cda276a595c",
+      "bytes": 567
+    },
+    {
+      "name": "02-undo-saved.md",
+      "sha256": "5adec513de2cc1672ff08e7de3bdff4cf8ddd37fce8e6f2fa39110c9fcbf503f",
+      "bytes": 73
+    },
+    {
+      "name": "03-redo-reopened.md",
+      "sha256": "fa6ab1275ca14df7920b2e05edd9a421e322af5c400bbeb5aca57cda276a595c",
+      "bytes": 567
+    },
+    {
+      "name": "04-swap-saved.md",
+      "sha256": "52ca74f9b11a29996fe9bafa009e0d2d3ba5bc6ce3a7319dc48cc041ba543626",
+      "bytes": 573
+    },
+    {
+      "name": "05-exported-graph.json",
+      "sha256": "4c0bfd9964b0f42f35afbf0338fe4e8bc0d11fc109928ca31c06cc48b9a3756e",
+      "bytes": 281
+    },
+    {
+      "name": "06-repeated-export.json",
+      "sha256": "38665290c40b3d4bcb38ef1ced867087c1ae0e01c6b32eae14ca1db553d6f420",
+      "bytes": 281
+    },
+    {
+      "name": "07-grep-before-sharing.json",
+      "sha256": "fc56c1d4a44f506af409eee56121a46f3cc8477672d2dc34607a5559e163d617",
+      "bytes": 344
+    },
+    {
+      "name": "08-grep-with-authored-synonym.json",
+      "sha256": "9551f2c6e8d5834edf27dae8a21666c6c419dbba1135953a68f8629fbf3a6d1a",
+      "bytes": 885
+    },
+    {
+      "name": "09-hazard-pending-source.md",
+      "sha256": "af0d51cc4f95d7e92b0b53844b583891178fde79347fa64b7cb917d2b07ae387",
+      "bytes": 650
+    },
+    {
+      "name": "10-dirty-graph-disk-before.json",
+      "sha256": "38665290c40b3d4bcb38ef1ced867087c1ae0e01c6b32eae14ca1db553d6f420",
+      "bytes": 281
+    },
+    {
+      "name": "11-dirty-graph-disk-after-refusal.json",
+      "sha256": "38665290c40b3d4bcb38ef1ced867087c1ae0e01c6b32eae14ca1db553d6f420",
+      "bytes": 281
+    },
+    {
+      "name": "12-preserved-interior-saved.json",
+      "sha256": "64dcdc420d874af43dc5efae59aaedac27173de104040df8f64949f4bfb36ee9",
+      "bytes": 282
+    },
+    {
+      "name": "13-export-after-save-with-hazard.json",
+      "sha256": "72a992b64475e3ebfc78665900cb106de119f3e05d0b8267b1b28ff8a2d9dafc",
+      "bytes": 395
+    },
+    {
+      "name": "14-trim-done-saved.md",
+      "sha256": "5e48e63b115302bb81525d6eb8a348de696fdd943e974c5fb9167cd9b104c033",
+      "bytes": 6386
+    },
+    {
+      "name": "15-post-trim-edit-saved.md",
+      "sha256": "d58874b0ff6548e0bffb59de36a8e9151fba437c5555de0b596c463e00008cc9",
+      "bytes": 6396
+    },
+    {
+      "name": "16-clean-export.md",
+      "sha256": "14c08e479f09302aa039dbd69bf8af6150a99d58b034001cf0e357ac47e28b8c",
+      "bytes": 2137
+    },
+    {
+      "name": "17-dirty-clean-disk-after-refusal.md",
+      "sha256": "14c08e479f09302aa039dbd69bf8af6150a99d58b034001cf0e357ac47e28b8c",
+      "bytes": 2137
+    },
+    {
+      "name": "18-preserved-clean-edit-saved.md",
+      "sha256": "8f641f475698ac2ce5ac3216fd530140cbfc111479511d37825ba75a4d28b6ff",
+      "bytes": 2163
+    }
+  ],
+  "dirtyJson": {
+    "actualPendingChange": "Saved Markdown adds Hazard; existing disk graph contains only Risk/Concern. The unsaved interior name is UNSAVED INTERIOR RC7.",
+    "visibleRefusal": "terraphim-lsp: the export buffer has unconfirmed changes; save or close it before exporting again.",
+    "diskBefore": "10-dirty-graph-disk-before.json",
+    "diskAfterRefusal": "11-dirty-graph-disk-after-refusal.json",
+    "preservedBufferSaved": "12-preserved-interior-saved.json",
+    "subsequentSuccess": "13-export-after-save-with-hazard.json",
+    "bufferObservation": "CUA screenshot showed exact interior text and dirty tab after refusal; subsequent native Save produced actual preserved bytes."
+  },
+  "trim": {
+    "level": "Tighten more ~20%",
+    "action": "Done",
+    "ghostCount": 11,
+    "prefix": "UPDATED ",
+    "anchorDelta": 8,
+    "cleanBytes": 2137
+  },
+  "passiveJsonScope": "Native code-action invocation in JSON produced no alternatives/Trim/Lab action menu. Full passive feature responses are separately verified by the actual released server protocol receipts; this UI observation alone is not protocol proof.",
+  "visualEvidence": {
+    "status": "CUA_TRANSCRIPT_ONLY_NO_PERSISTED_IMAGE",
+    "observedImages": "Tool transcript includes actual refusal toast, dirty JSON interior before/after, Trim preview, clean export and dirty-clean refusal/preserved buffer.",
+    "captureAttempts": [
+      "macOS Screenshot app launcher timed out; helper launch failed after a long tool stall",
+      "CmdShift4 did not invoke capture; following Space entered the editor and was immediately undone before save",
+      "One Preview File > Take Screenshot > From Window attempt produced no overlay or new image"
+    ],
+    "limitation": "No durable screenshot file is claimed. No alternate capture technology or fabricated image was used."
+  },
+  "automationNotes": [
+    "Prefix save preceded asynchronous annotation reconciliation; second native save after settlement produced all11 correctly shifted anchors.",
+    "Screenshot shortcut inserted one space into dirty JSON; native undo removed that space before preserved bytes were saved."
+  ],
+  "scopeLimits": [
+    "Native source installation only; actual compiled release archive and official registry installation remain pending.",
+    "No all41 browser-editor UI parity claim.",
+    "JSONC dirty handling has actual released-binary protocol proof; this native default graph filename is JSON.",
+    "The Trim fixture includes preauthored annotations and is explicitly input; new Concern/Hazard authoring used the separate plain Markdown document.",
+    "Zed application fork remains separate."
+  ],
+  "inputSeparation": {
+    "plainSource": "The initial Risk sentence is the independently identified plain input; Concern and Hazard annotations were created through native commands. Native undo output02 equals that original input.",
+    "plainInputSha256": "5adec513de2cc1672ff08e7de3bdff4cf8ddd37fce8e6f2fa39110c9fcbf503f",
+    "trimFixture": "Trim starts from a separately preauthored fixture. Its existing synonym annotation is input; Done generated the11 ghost annotations in output14.",
+    "trimInputSha256": "80b4a8b625920ff9a3b6581c5f64b9fbb232cb79a813fdb573a0b0ba4c5694d4"
+  },
+  "releasedGrep": {
+    "version": "1.21.19",
+    "binarySha256": "ce20e2bf87c6753c717dade4ac7baac98b05d0be9cb39af1f3afbcbf6e5c47de",
+    "release": "https://github.com/terraphim/terraphim-clients/releases/tag/v1.21.19",
+    "searchOnly": true,
+    "query": "concern",
+    "baselinePassages": 0,
+    "sharedGraphPassages": 1,
+    "graphFile": "06-repeated-export.json",
+    "sourcePassage": "Risk is manageable. The release decision is to retain a backup supplier.",
+    "synthesis": "Not exercised in this bounded extension qualification."
+  },
+  "review": "Prepared for independent review; publication admission remains a separate operator decision."
+}