diff --git a/docs/qualification/v0-2-0/README.md b/docs/qualification/v0-2-0/README.md index 197c581..9dda56a 100644 --- a/docs/qualification/v0-2-0/README.md +++ b/docs/qualification/v0-2-0/README.md @@ -7,3 +7,5 @@ The numbered files are actual saved outputs. Outputs 01–04 prove authoring, un 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. + +The separately [verified compiled-package installation](compiled-package/README.md) loads the actual downloaded CI WASM. Its [receipt](compiled-package/compiled-package-qualification.json) records the archive/module identities and fresh native saved outputs. diff --git a/docs/qualification/v0-2-0/compiled-package/01-created-saved.md b/docs/qualification/v0-2-0/compiled-package/01-created-saved.md new file mode 100644 index 0000000..4861834 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/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/compiled-package/02-undo-saved.md b/docs/qualification/v0-2-0/compiled-package/02-undo-saved.md new file mode 100644 index 0000000..bb5f26c --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/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/compiled-package/03-redo-reopened.md b/docs/qualification/v0-2-0/compiled-package/03-redo-reopened.md new file mode 100644 index 0000000..4861834 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/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/compiled-package/04-swap-saved.md b/docs/qualification/v0-2-0/compiled-package/04-swap-saved.md new file mode 100644 index 0000000..0791d94 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/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/compiled-package/05-exported-graph.json b/docs/qualification/v0-2-0/compiled-package/05-exported-graph.json new file mode 100644 index 0000000..4053867 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/05-exported-graph.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/compiled-package/06-repeated-export.json b/docs/qualification/v0-2-0/compiled-package/06-repeated-export.json new file mode 100644 index 0000000..0d2fdd0 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/06-repeated-export.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/compiled-package/07-grep-before-sharing.json b/docs/qualification/v0-2-0/compiled-package/07-grep-before-sharing.json new file mode 100644 index 0000000..a036888 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/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/compiled-package/08-grep-with-authored-synonym.json b/docs/qualification/v0-2-0/compiled-package/08-grep-with-authored-synonym.json new file mode 100644 index 0000000..7712b45 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/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/compiled-package/09-hazard-pending-source.md b/docs/qualification/v0-2-0/compiled-package/09-hazard-pending-source.md new file mode 100644 index 0000000..26e2014 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/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/compiled-package/10-dirty-graph-disk-before.json b/docs/qualification/v0-2-0/compiled-package/10-dirty-graph-disk-before.json new file mode 100644 index 0000000..0d2fdd0 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/10-dirty-graph-disk-before.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/compiled-package/11-dirty-graph-disk-after-refusal.json b/docs/qualification/v0-2-0/compiled-package/11-dirty-graph-disk-after-refusal.json new file mode 100644 index 0000000..0d2fdd0 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/11-dirty-graph-disk-after-refusal.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/compiled-package/12-preserved-interior-saved.json b/docs/qualification/v0-2-0/compiled-package/12-preserved-interior-saved.json new file mode 100644 index 0000000..3797a80 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/12-preserved-interior-saved.json @@ -0,0 +1,17 @@ +{ + "name": "UNSAVED INTERIOR RELEASED", + "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/compiled-package/13-export-after-save-with-hazard.json b/docs/qualification/v0-2-0/compiled-package/13-export-after-save-with-hazard.json new file mode 100644 index 0000000..c46b18b --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/13-export-after-save-with-hazard.json @@ -0,0 +1,23 @@ +{ + "name": "Document alternatives", + "data": { + "hazard": { + "id": 1, + "nterm": "risk", + "display_value": "Risk", + "pinned": false + }, + "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/compiled-package/14-trim-done-saved.md b/docs/qualification/v0-2-0/compiled-package/14-trim-done-saved.md new file mode 100644 index 0000000..ecb44de --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/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/compiled-package/15-reopened-prefix-edit-saved.md b/docs/qualification/v0-2-0/compiled-package/15-reopened-prefix-edit-saved.md new file mode 100644 index 0000000..a070151 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/15-reopened-prefix-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/compiled-package/16-clean-export.md b/docs/qualification/v0-2-0/compiled-package/16-clean-export.md new file mode 100644 index 0000000..5db0250 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/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/compiled-package/17-dirty-clean-disk-after-refusal.md b/docs/qualification/v0-2-0/compiled-package/17-dirty-clean-disk-after-refusal.md new file mode 100644 index 0000000..5db0250 --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/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/compiled-package/18-preserved-clean-edit-saved.md b/docs/qualification/v0-2-0/compiled-package/18-preserved-clean-edit-saved.md new file mode 100644 index 0000000..7a9c8ba --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/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/compiled-package/README.md b/docs/qualification/v0-2-0/compiled-package/README.md new file mode 100644 index 0000000..cd69ebe --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/README.md @@ -0,0 +1,7 @@ +# Released Zed package qualification + +These are actual saved outputs from a fresh stock-Zed 1.23.3 profile on macOS ARM64 using the downloaded Terraphim LSP extension 0.2.0 archive. The installed 319,339-byte WASM exactly matches the original CI release artifact. The extension automatically downloaded the checksum-verified public RC7 server. + +The receipt binds the public release, immutable source, CI artifact, installed module, server and each saved output. It distinguishes authored alternatives from word swapping and from the preauthored Trim input. The dirty-JSON case uses an unsaved interior edit while a different graph is waiting to export. Both buffer and disk were preserved, then a subsequent intentional save allowed export. + +This is a manual compiled-package installation through Zed's Install Dev Extension action, not an official catalog installation. Functional observations exist in the native tool transcript; no downloadable screenshot or video is claimed. Source-dev qualification remains in the sibling source-qualification.json with its distinct module hash. The Zed application fork is separate. diff --git a/docs/qualification/v0-2-0/compiled-package/compiled-package-qualification.json b/docs/qualification/v0-2-0/compiled-package/compiled-package-qualification.json new file mode 100644 index 0000000..cf756cd --- /dev/null +++ b/docs/qualification/v0-2-0/compiled-package/compiled-package-qualification.json @@ -0,0 +1,194 @@ +{ + "schema": 1, + "at": "2026-10-14T17:30:21.403459+00:00", + "status": "PASS", + "scope": "stock-zed-released-compiled-package", + "qualifiedCommit": "b75b475adebe42604ac9ba86023b884c7049bc58", + "extensionId": "terraphim-lsp", + "version": "0.2.0", + "host": { + "application": "Zed", + "version": "1.23.3", + "platform": "macOS ARM64" + }, + "release": { + "id": 412978715, + "url": "https://github.com/terraphim/zed-terraphim/releases/tag/v0.2.0" + }, + "ciArtifact": { + "id": 11914862733, + "name": "zed-release-v0.2.0", + "createdAt": "2026-10-14T17:10:45Z", + "bytes": 127105, + "sha256": "83659dc7b9aac0093b06df3dd68b24d4805c619138a889574ee7ccfe36ea665b" + }, + "archive": { + "name": "terraphim-lsp-0.2.0.tar.gz", + "url": "https://github.com/terraphim/zed-terraphim/releases/download/v0.2.0/terraphim-lsp-0.2.0.tar.gz", + "bytes": 121025, + "sha256": "efaa6667c75d449490f0168c0665886cb1fd78a34c1c25531cdf9d6b189d50df" + }, + "installedModule": { + "sha256": "bc3107fdeae0f24f6bd0d221ff2c12ecf5eeb74682357c11a6bd21051deb5f1d", + "bytes": 319339 + }, + "server": { + "releaseTag": "terraphim_lsp-v1.22.0-rc.7", + "source": "4fb62d337c306a9105c5e872f3400f3052a2caef", + "sha256": "ed60697248dfbef1d3b731e5f758fd7f02c00c74b3da8581df11dd78fa2e32cd", + "bytes": 13497968 + }, + "installation": "Stock Zed Install Dev Extension selected the actual downloaded four-file archive directory with no Cargo.toml. Installed module is the original Linux CI release WASM. Fresh isolated profile automatically downloaded the pinned checksum-verified public RC7 universal server; no manual binary/cache seed, binary.path override or PATH fallback. This is a manual compiled-package install, not an official catalog installation.", + "checks": { + "defaultProvisioning": "PASS", + "cacheRestart": "PASS", + "createApplySaveUndoRedoReopen": "PASS", + "synonymGraphExportTwice": "PASS", + "dirtyJsonRefusal": "PASS", + "trimDoneAnchorShift": "PASS", + "cleanExportDirtyRefusal": "PASS", + "releasedGrepSharedSynonym": "PASS" + }, + "dirtyJson": { + "actualPendingChange": "Saved Markdown adds Hazard while the existing disk graph contains only Risk/Concern; the unsaved interior name is UNSAVED INTERIOR RELEASED.", + "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 transcript image showed the exact unsaved interior text and dirty tab after refusal. Subsequent native Save preserved those actual bytes, and the next native export added Hazard." + }, + "trim": { + "level": "Tighten more ~20%", + "action": "Done", + "ghostCount": 11, + "prefix": "UPDATED ", + "anchorDelta": 8, + "cleanBytes": 2137 + }, + "inputSeparation": { + "plainInputSha256": "5adec513de2cc1672ff08e7de3bdff4cf8ddd37fce8e6f2fa39110c9fcbf503f", + "plainSource": "Concern and Hazard were newly authored through native commands. Output01 registers Concern while Risk remains active; output04 separately swaps the word to Concern. Native undo output02 equals the plain input.", + "trimInputSha256": "80b4a8b625920ff9a3b6581c5f64b9fbb232cb79a813fdb573a0b0ba4c5694d4", + "trimFixture": "The separately preauthored Trim input already contains its synonym annotation. Done created the11 ghost annotations; this input is not represented as newly authored output." + }, + "releasedGrep": { + "version": "1.21.19", + "binarySha256": "ce20e2bf87c6753c717dade4ac7baac98b05d0be9cb39af1f3afbcbf6e5c47de", + "release": "https://github.com/terraphim/terraphim-clients/releases/tag/v1.21.19", + "query": "concern", + "searchOnly": true, + "baselinePassages": 0, + "sharedGraphPassages": 1, + "sourcePassage": "Risk is manageable. The release decision is to retain a backup supplier.", + "synthesis": "Not exercised in this bounded extension qualification." + }, + "visualEvidence": { + "status": "CUA_TRANSCRIPT_ONLY_NO_PERSISTED_IMAGE", + "observations": "Actual tool images show the native install, word swap, dirty JSON interior/refusal, Trim preview, clean output and dirty-clean refusal/preserved buffer.", + "limitation": "No durable screenshot or video file is claimed; earlier source-run capture failures remain separately recorded. No additional capture retries or substitute images were used." + }, + "automationNotes": [ + "Initial chooser selection used remembered source folder before Go To settled. Source-linked extension was detected by hash/path assertion and removed through UI before any Markdown was opened. Then observed chooser selected exact released four-file directory. No source-linked native outputs are counted.", + "The prefix edit saved before asynchronous annotation reconciliation finished; a second native Save after settlement produced all11 correctly shifted anchors." + ], + "scopeLimits": [ + "Manual installation of the genuine compiled GitHub release; official Zed catalog submission/installation remains pending.", + "Native host qualification is macOS ARM64, not every OS or all41 browser-editor requirements.", + "JSONC dirty handling is separately proved by released-server protocol tests; this native graph filename is JSON.", + "Zed application fork remains separate." + ], + "qualificationMeaning": "The eight listed functional saved-output checks passed using the actual downloaded compiled extension. Visual and catalog limits remain explicit.", + "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": "38665290c40b3d4bcb38ef1ced867087c1ae0e01c6b32eae14ca1db553d6f420", + "bytes": 281 + }, + { + "name": "06-repeated-export.json", + "sha256": "4c0bfd9964b0f42f35afbf0338fe4e8bc0d11fc109928ca31c06cc48b9a3756e", + "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": "4c0bfd9964b0f42f35afbf0338fe4e8bc0d11fc109928ca31c06cc48b9a3756e", + "bytes": 281 + }, + { + "name": "11-dirty-graph-disk-after-refusal.json", + "sha256": "4c0bfd9964b0f42f35afbf0338fe4e8bc0d11fc109928ca31c06cc48b9a3756e", + "bytes": 281 + }, + { + "name": "12-preserved-interior-saved.json", + "sha256": "c28c5bd17356a65df8f7fc9dfff44580a2241ca98bb8163eb93414f1d1fd0edd", + "bytes": 287 + }, + { + "name": "13-export-after-save-with-hazard.json", + "sha256": "6d544d87bcd8bbfed545136e1bb663bc5e8876a37e0e7b11458c072fb8d1df05", + "bytes": 395 + }, + { + "name": "14-trim-done-saved.md", + "sha256": "5e48e63b115302bb81525d6eb8a348de696fdd943e974c5fb9167cd9b104c033", + "bytes": 6386 + }, + { + "name": "15-reopened-prefix-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 + } + ] +}