Novice browser user-test, ACE triage, and Option B' fixes

.claude/skills/tutorial-glossary/SKILL.md

@@ -47,7 +47,7 @@ Sources are not ranked against each other. Each supplies a **kind** of definitio
 - **Term:** add a node to `glossary/terms/terms.ttl` (`glid:term-<slug>`, `gl:label`, `gl:loadBearing true` only if a Foundations paragraph or skill relies on it). A term with no edge is an orphan and fails `check`.
 - **Source:** add to `glossary/sources/sources.ttl` with `gl:kind`, `gl:rank`, and either a file (`gl:sha256`, `gl:localPath` under the gitignored `glossary/sources/local/`) or a non-file source (`gl:url` and `gl:retrievedOn`, or `gl:commit`). Keep N small; prefer an edge in an existing source.
 - **Edge:** add to `glossary/definitions/<source>.ttl` as `glid:def-<source>--<term>` with `gl:source`, `gl:term`, `gl:text`, `gl:locator`, `gl:status gl:proposed`, and `gl:quote` plus `gl:pdfPage` for files.
-- Write Turtle through the `glossary.graph.save_graph` helper (canonical, byte-deterministic), not by hand, or `check` will report drift. Then run `check`. On Z's machine also run `verify-sources`.
+- Write Turtle through the `glossary.graph.save_graph` helper (canonical, byte-deterministic), not by hand, or `check` will report drift. Then run `check`. On Z's machine also run `verify-sources` (where to get each source file and where to put it: "Getting the source files" in `glossary/README.md`).
 - Tell the ACE (or Z) what you proposed; they triage and Z confirms. Log it in `decisions/log.md` if it changes a confirmed definition (only Z can change one).
 
 ## Worktree and CI safety

.claude/skills/user-testing/SKILL.md

@@ -77,6 +77,36 @@ some files (e.g. notebook text) from the wrong branch state while reading others
 from its own worktree — a mixed-path read that produces false findings. Confirmed as the cause of a
 false NEEDS-FIX verdict in the first grid run (`decisions/log.md` DL-085).
 
+### Browser read-through diaries: evidence rules (binding; from DL-100, DL-102, DL-103)
+
+When a persona reads the rendered site page by page in a browser instead of executing cells
+(the longitudinal read-through mode), the checklist above still applies to what each page shows,
+and these four rules apply to how the diary is written:
+
+1. **Read prose with `get_page_text`.** It is the required primary reading tool for page text.
+   `read_page`'s accessibility tree truncates long text nodes with an ellipsis and renders inline
+   code spans as separate child nodes, so prose read from it loses its identifiers, operators and
+   keywords; that is the likely cause of round 1's "sentence cut off" findings, every one of which
+   was an intact sentence on the page (DL-100). Screenshots are for figures and layout, not for
+   reading prose.
+2. **Minimum evidence before an observation is written.** For each page: the page actually opened
+   in the browser at its real URL (never a guessed slug), its text extracted, every figure on it
+   screenshotted and described from the screenshot, and any sentence quoted in the diary copied from
+   the extracted text. An entry written from memory, from an earlier page, or from the notebook
+   source instead of the rendered page is not a diary entry; say "not read" instead.
+3. **String-level verification of any reported defect.** A finding that names a specific string
+   (a caption, a printed output, a qualified name, a number, a character count) must be checked
+   against the extracted page text before it is written, and the entry must say where on the page
+   the string appears. Page-level verification ("I read this page") does not catch a quoted string
+   that is not there: round 2 reported a caption and a doubled qualified name on `/part-def` that
+   exist nowhere on the page or in its source (DL-102, R2-1 and R2-2).
+4. **One reader per diary, or an explicit hand-off marker.** If a fresh agent instance continues a
+   diary, the diary carries a marker at the hand-off naming the page range each instance read, and
+   the continuing instance answers interview questions only about its own range. Without this the
+   ACE cannot weight interview testimony: round 2's instance could not say which pages it had opened
+   and answered about pages it had not (DL-102, M2 and M4). A diary written at roughly one minute
+   per page is a skim and its load ratings measure length, not difficulty; record the dwell per page.
+
 ## Report format
 
 ```

chapters/ch01-system-purpose/index.md

@@ -23,9 +23,9 @@ See [setup](../../docs/setup.md) to provision Python and the OpenSysML binary be
 
 ## Method
 
-The four notebooks build the model of the toaster, the subject the tutorial's layers describe. Notebook 01 states the toaster's purpose functionally: `ToastingSystem`, the abstract subject, performs `ToastBread`, an action with typed `Bread` in and `Toast` out flows and the acceptance language as its `doc`. Notebooks 02 through 04 build the logical composition: two concrete subsystem placeholders (`HeatingSystem`, `ControlSystem`) with no content yet, the specialization that makes the concrete whole (`Toaster`) a kind of the subject it names, and the composition that gives `Toaster` a `heating` part and a `control` part.
+The four notebooks build the model of the toaster, the subject the tutorial's layers describe. Notebook 01 states the toaster's purpose functionally: `ToastingSystem`, the [abstract](../../docs/glossary.md#abstract-definition) subject, performs `ToastBread`, an action with typed `Bread` in and `Toast` out flows and the acceptance language as its `doc`. Notebooks 02 through 04 build the logical composition: two concrete subsystem placeholders (`HeatingSystem`, `ControlSystem`) with no content yet, the specialization that makes the concrete whole (`Toaster`) a kind of the subject it names, and the composition that gives `Toaster` a `heating` part and a `control` part.
 
-By the end of notebook 04, `Toaster :> ToastingSystem` performs the toasting purpose and owns both subsystems. Neither subsystem carries a mechanism, an interface, or a value yet. That is later chapters' work, once a mechanism has been selected for each.
+By the end of notebook 04, `Toaster :> ToastingSystem` performs the toasting purpose and owns both subsystems. Neither subsystem carries a [mechanism](../../docs/glossary.md#mechanism), an interface, or a value yet. That is later chapters' work, once a mechanism has been selected for each.
 
 ## Expected result
 

chapters/ch02-requirements/index.md

@@ -6,7 +6,9 @@ title: Overview
 
 ## Purpose
 
-Chapter 2 asks: what must the toaster do, and what do we assume about the conditions under which it operates? After completing this chapter, the model has a requirement definition, two named usages of `Toaster`, and the first engineering judgment record.
+Chapter 2 asks: what must the toaster do, and what do we assume about the conditions under which it operates? After completing this chapter, the model has a requirement definition, two named usages of `Toaster`, and the first engineering [judgment record](../../docs/glossary.md#judgment-record).
+
+A judgment record is a written, checkable record of an engineering judgment call, and following Hawkins et al. (2011) there are three kinds. An `asserted_context` records a context or assumption that is asserted to be appropriate for the argument elements it applies to. An `asserted_solution` records evidence cited as a solution that is asserted to be sufficient to support a claim. An `asserted_inference` records a claim said to be supported by other claims, with the inference asserted to be appropriate and sufficient. Notebook 03 builds the first of these, an `asserted_context`; a record states what is being asserted and does not settle the question, so its disposition stays `pending`.
 
 ## Ingredients
 

chapters/ch03-measures/01-moe-definition.ipynb

@@ -277,15 +277,15 @@
      "name": "stdout",
      "output_type": "stream",
      "text": [
-      "MoE if the split names who cares and frames the measure as acceptance; MoP if its threshold is derived from a stated MoE with a means of checking (architecture-layers skill).\n"
+      "MoE if the split names who cares and frames the measure as acceptance; MoP if its threshold is derived from a stated MoE with a means of checking (SEBoK's MoE/MoP distinction, PDF 1562).\n"
      ]
     }
    ],
    "source": [
     "scope = (\"ToasterDemo\")\n",
     "criteria = (\"MoE if the split names who cares and frames the measure as \"\n",
     "        \"acceptance; MoP if its threshold is derived from a stated MoE with a \"\n",
-    "        \"means of checking (architecture-layers skill).\")\n",
+    "        \"means of checking (SEBoK's MoE/MoP distinction, PDF 1562).\")\n",
     "print(criteria)"
    ]
   },

chapters/ch03-measures/index.md

@@ -23,7 +23,7 @@ See [setup](../../docs/setup.md) to provision Python and the OpenSysML binary be
 
 ## Method
 
-Notebook 01 applies the `TimelyToast` requirement definition from Chapter 2 to the model as `timely : TimelyToast`, then records the modeling judgment behind it: whether toast time is a measure of effectiveness (the user's acceptance) or a measure of performance (an engineering figure), a case-specific decision this chapter justifies rather than assumes. Notebook 02 folds a satisfaction claim into `slow`'s own body, `assert not satisfy timely by slow`, and evaluates it against the model's own values. Notebook 03 writes the chapter's `asserted_solution` judgment record, stating what the evaluated claim supports and what it does not decide about `nominal`. Notebook 04 closes the three-part requirement anatomy (description, rationale, verification method) by adding `TimelyToastTest`: a `verification def` (§7.24) that declares the subject under test and an objective naming `timely` as the requirement to verify.
+Notebook 01 applies the `TimelyToast` requirement definition from Chapter 2 to the model as `timely : TimelyToast`, then records the modeling judgment behind it: whether toast time is a [measure of effectiveness](../../docs/glossary.md#measure-of-effectiveness-moe) (the user's acceptance) or a [measure of performance](../../docs/glossary.md#measure-of-performance-mop) (an engineering figure), a case-specific decision this chapter justifies rather than assumes. Notebook 02 folds a satisfaction claim into `slow`'s own body, `assert not satisfy timely by slow`, and evaluates it against the model's own values. Notebook 03 writes the chapter's `asserted_solution` judgment record, stating what the evaluated claim supports and what it does not decide about `nominal`. Notebook 04 closes the three-part requirement anatomy (description, rationale, verification method) by adding `TimelyToastTest`: a `verification def` (§7.24) that declares the subject under test and an objective naming `timely` as the requirement to verify.
 
 ## Expected result
 

chapters/ch05-architecture/02-allocate.ipynb

@@ -138,7 +138,7 @@
    "id": "cell-11",
    "metadata": {},
    "source": [
-    "`find_allocations` shows `heatAllocation`'s real ends: the first is the feature chain `toastBread.applyHeat` — `toastBread`, declared on `ToastingSystem` and inherited by `Toaster`, then `applyHeat`, nested inside the `ToastBread` action — and the second is `Toaster::heating`, a usage, not `HeatingSystem` the definition. `perform_relationships` shows `HeatingSystem` (the definition `Toaster::heating` is typed by) performing `ApplyHeat`: the allocation targets the usage; the performer relationship is stated on its type. Usage-level allocation is exactly this distinction, not a detail to blur past."
+    "`find_allocations` shows `heatAllocation`'s real ends: the first is the [feature chain](../../docs/glossary.md#feature-chain) `toastBread.applyHeat` — `toastBread`, declared on `ToastingSystem` and inherited by `Toaster`, then `applyHeat`, nested inside the `ToastBread` action — and the second is `Toaster::heating`, a usage, not `HeatingSystem` the definition. `perform_relationships` shows `HeatingSystem` (the definition `Toaster::heating` is typed by) performing `ApplyHeat`: the allocation targets the usage; the performer relationship is stated on its type. Usage-level allocation is exactly this distinction, not a detail to blur past."
    ]
   },
   {

chapters/ch05-architecture/03-interfaces.ipynb

@@ -66,7 +66,7 @@
    "id": "cell-05",
    "metadata": {},
    "source": [
-    "`~DurationPort` is the conjugate of `DurationPort`: `durationIn` receives what a `DurationPort` sends, the SysML v2 idiom for matching a port to its interface partner."
+    "`~DurationPort` is the [conjugate](../../docs/glossary.md#conjugated-port) of `DurationPort`: `durationIn` receives what a `DurationPort` sends, the SysML v2 idiom for matching a port to its interface partner."
    ]
   },
   {

chapters/ch05-architecture/index.md

@@ -28,7 +28,7 @@ The chapter begins with navigation: before adding new relationships, you need to
 
 Notebook 02 introduces `allocate`, which answers the question "which component is responsible for which function?" `HeatingSystem` becomes an abstract logical component that performs `ApplyHeat` (Chapter 4's function, nested inside `ToastBread`), and a named allocation usage connects the two directly.
 
-Notebook 03 introduces `port def` and `interface`, which answer "what connection point does each component expose, and how are they joined?" `HeatingSystem` and `ControlSystem` each get a port, joined by a named interface showing where the `duration` signal `ApplyHeat` has declared since Chapter 4 would flow, once something produces it. It closes with `render_toolkit_interconnection()`, which shells out to sysml-toolkit's own `viz` CLI and PlantUML to render the connection as a displayed SVG diagram with each conjugated port drawn as its own named box, rather than collapsed to a single edge label.
+Notebook 03 introduces `port def` and `interface`, which answer "what connection point does each component expose, and how are they joined?" `HeatingSystem` and `ControlSystem` each get a port, joined by a named interface showing where the `duration` signal `ApplyHeat` has declared since Chapter 4 would flow, once something produces it. It closes with `render_toolkit_interconnection()`, which shells out to sysml-toolkit's own `viz` CLI and PlantUML to render the connection as a displayed SVG diagram with each [conjugated port](../../docs/glossary.md#conjugated-port) drawn as its own named box, rather than collapsed to a single edge label.
 
 ## Expected result
 

chapters/ch06-recursive-decomp/02-second-level.ipynb

@@ -203,7 +203,7 @@
      "name": "stdout",
      "output_type": "stream",
      "text": [
-      "MoE if the split names who cares and frames the measure as acceptance; MoP if its threshold is derived from a stated MoE with a means of checking (architecture-layers skill).\n"
+      "MoE if the split names who cares and frames the measure as acceptance; MoP if its threshold is derived from a stated MoE with a means of checking (SEBoK's MoE/MoP distinction, PDF 1562).\n"
      ]
     }
    ],
@@ -212,7 +212,7 @@
     "framing_criteria = (\n",
     "    \"MoE if the split names who cares and frames the measure as acceptance; MoP \"\n",
     "    \"if its threshold is derived from a stated MoE with a means of checking \"\n",
-    "    \"(architecture-layers skill).\"\n",
+    "    \"(SEBoK's MoE/MoP distinction, PDF 1562).\"\n",
     ")\n",
     "print(framing_criteria)"
    ]