Interleave Leaf asks with the explanation they turn on

examples/corpus.html

@@ -228,8 +228,8 @@ <h1>Where the heat goes</h1>
         You sent me the meter readings, the thermostat log, and the survey the installer
         left behind. This is what they say together. A chart has no words to select, so
         click one and the comment lands on the whole picture — say which number you want
-        and I will put it in the next version. The last section asks which measure to
-        pay for first.
+        and I will put it in the next version. After the survey of where it leaves, I
+        ask which measure to book first.
       </p>
 
       <section id="heat-years-section">
@@ -316,39 +316,6 @@ <h2>Where it leaves</h2>
         </lf-chart>
       </section>
 
-      <section id="heat-weather">
-        <h2>Against the weather</h2>
-        <p id="heat-weather-note">
-          Every week sits at its own average outside temperature, so a colder winter
-          cannot be mistaken for a leakier house. The two runs are the same house six
-          weeks apart: the second sits about
-          <lf-num
-            id="heat-weather-gap"
-            source="heat-weather-gap"
-            at="2026-02-01T12:00:00Z"
-            via="uv run analyse-heat --weather-normalise"
-            >40 kWh a week</lf-num
-          >
-          below the first at the same temperature, which is the draught-proofing showing
-          up.
-        </p>
-        <lf-chart id="heat-response" kind="dots" y="gas, kWh a week">
-          <pre>
-outside average, before, after
-2.1, 604,
-3.0, 588,
-3.4, 561,
-4.2, 538,
-5.0, 512,
-6.1, 470,
-2.6, , 542
-3.8, , 498
-5.2, , 470
-6.4, , 449
-</pre>
-        </lf-chart>
-      </section>
-
       <lf-decision id="heat-first-decision">
         <h2>Which measure should be booked first?</h2>
         <p id="heat-first-note">
@@ -387,6 +354,39 @@ <h2>Which measure should be booked first?</h2>
           </lf-option>
         </lf-options>
       </lf-decision>
+
+      <section id="heat-weather">
+        <h2>Against the weather</h2>
+        <p id="heat-weather-note">
+          Every week sits at its own average outside temperature, so a colder winter
+          cannot be mistaken for a leakier house. The two runs are the same house six
+          weeks apart: the second sits about
+          <lf-num
+            id="heat-weather-gap"
+            source="heat-weather-gap"
+            at="2026-02-01T12:00:00Z"
+            via="uv run analyse-heat --weather-normalise"
+            >40 kWh a week</lf-num
+          >
+          below the first at the same temperature, which is the draught-proofing showing
+          up.
+        </p>
+        <lf-chart id="heat-response" kind="dots" y="gas, kWh a week">
+          <pre>
+outside average, before, after
+2.1, 604,
+3.0, 588,
+3.4, 561,
+4.2, 538,
+5.0, 512,
+6.1, 470,
+2.6, , 542
+3.8, , 498
+5.2, , 470
+6.4, , 449
+</pre>
+        </lf-chart>
+      </section>
 </lf-tab>
 
 <lf-tab id="corpus-live-progress" label="Live">

examples/heat-loss.html

@@ -22,8 +22,8 @@ <h1>Where the heat goes</h1>
         You sent me the meter readings, the thermostat log, and the survey the installer
         left behind. This is what they say together. A chart has no words to select, so
         click one and the comment lands on the whole picture — say which number you want
-        and I will put it in the next version. The last section asks which measure to
-        pay for first.
+        and I will put it in the next version. After the survey of where it leaves, I
+        ask which measure to book first.
       </p>
 
       <section id="heat-years-section">
@@ -110,39 +110,6 @@ <h2>Where it leaves</h2>
         </lf-chart>
       </section>
 
-      <section id="heat-weather">
-        <h2>Against the weather</h2>
-        <p id="heat-weather-note">
-          Every week sits at its own average outside temperature, so a colder winter
-          cannot be mistaken for a leakier house. The two runs are the same house six
-          weeks apart: the second sits about
-          <lf-num
-            id="heat-weather-gap"
-            source="heat-weather-gap"
-            at="2026-02-01T12:00:00Z"
-            via="uv run analyse-heat --weather-normalise"
-            >40 kWh a week</lf-num
-          >
-          below the first at the same temperature, which is the draught-proofing showing
-          up.
-        </p>
-        <lf-chart id="heat-response" kind="dots" y="gas, kWh a week">
-          <pre>
-outside average, before, after
-2.1, 604,
-3.0, 588,
-3.4, 561,
-4.2, 538,
-5.0, 512,
-6.1, 470,
-2.6, , 542
-3.8, , 498
-5.2, , 470
-6.4, , 449
-</pre>
-        </lf-chart>
-      </section>
-
       <lf-decision id="heat-first-decision">
         <h2>Which measure should be booked first?</h2>
         <p id="heat-first-note">
@@ -181,6 +148,39 @@ <h2>Which measure should be booked first?</h2>
           </lf-option>
         </lf-options>
       </lf-decision>
+
+      <section id="heat-weather">
+        <h2>Against the weather</h2>
+        <p id="heat-weather-note">
+          Every week sits at its own average outside temperature, so a colder winter
+          cannot be mistaken for a leakier house. The two runs are the same house six
+          weeks apart: the second sits about
+          <lf-num
+            id="heat-weather-gap"
+            source="heat-weather-gap"
+            at="2026-02-01T12:00:00Z"
+            via="uv run analyse-heat --weather-normalise"
+            >40 kWh a week</lf-num
+          >
+          below the first at the same temperature, which is the draught-proofing showing
+          up.
+        </p>
+        <lf-chart id="heat-response" kind="dots" y="gas, kWh a week">
+          <pre>
+outside average, before, after
+2.1, 604,
+3.0, 588,
+3.4, 561,
+4.2, 538,
+5.0, 512,
+6.1, 470,
+2.6, , 542
+3.8, , 498
+5.2, , 470
+6.4, , 449
+</pre>
+        </lf-chart>
+      </section>
     </main>
   </body>
 </html>

skills/leaf/SKILL.md

@@ -93,8 +93,9 @@ guidance <page>` lists the available audiences, and `leaf page guidance <page>
 <audience>` prints one guide. Read the assigned audience before acting in that
 role. List the page's audiences and read `author` guidance when it is available.
 
-Every decision has a control beside its evidence. A page that needs approval declares
-sign-off; an informative page does not. Save freely as the subject changes and
+A decision sits where the page has just made it answerable, with its control beside
+the evidence it turns on and the rest of the page after it. A page that needs
+approval declares sign-off; an informative page does not. Save freely as the subject changes and
 stamp meaningful checkpoints. Use status detail for progress between revisions.
 Keep the waiter alive while work continues so comments can affect the next step.
 

skills/leaf/packages/default/registry.json

@@ -858,7 +858,7 @@
     "x-upgrade": false
   },
   "lf-tabs": {
-    "description": "Workstreams on one page: use one family when broad context branches into focused work. Keep the shared title and lede before it, put the current stream first, and keep earlier context intact in a sibling panel so its stable ids retain their comments and decisions. Ordering gives the first panel emphasis and makes it the default for a reader with no remembered panel or reading position. A saved panel or restored position takes precedence because the open tab is the reader's view state — remembered per browser tab like scroll position, never an action, never carried by a version. Each lf-tab is a self-contained sub-context with its own prose and widgets, while Threads, Decisions, versions, and sign-off remain global. Find-in-page, decision travel, and comment-anchor jumps open the owning tab. Children are lf-tab elements only; unupgraded, panels stack as labeled sections.",
+    "description": "Workstreams on one page: use one family when several are live at once. Keep the shared title and lede before it, put the current stream first, and remove an earlier run once the current work no longer depends on it, keeping the context it still needs, and any passage whose id anchors an open thread or holds a standing decision, in a collapsed details inside the relevant tab. Ordering gives the first panel emphasis and makes it the default for a reader with no remembered panel or reading position. A saved panel or restored position takes precedence because the open tab is the reader's view state — remembered per browser tab like scroll position, never an action, never carried by a version. Each lf-tab is a self-contained sub-context with its own prose and widgets, while Threads, Decisions, versions, and sign-off remain global. Find-in-page, decision travel, and comment-anchor jumps open the owning tab. Children are lf-tab elements only; unupgraded, panels stack as labeled sections.",
     "type": "object",
     "properties": {
       "id": {

skills/leaf/references/authoring-decisions.md

@@ -5,12 +5,18 @@ registry entries for the exact widget contracts.
 
 ## Asks and sign-off
 
-Make the ask self-contained: put each alternative's title, case, and
-decision-relevant evidence or preview inside the option itself. Use a short
-option that points elsewhere only to select among sections or work items that
-already exist independently of the decision; do not create separate sections
-to hold an ask's alternatives. Allow multiple picks only when several options
-may stand.
+Put each ask where the reader has just read what it turns on, and let the page
+go on explaining after it. That point is the paragraph, list item, table, or
+chart that makes the question answerable. An ask about one item of a list
+follows that item, and an ask that turns on a claim follows the claim rather
+than the backing collapsed under it. Only an ask that turns on the whole page
+comes last.
+
+Each option carries its own title, case, and decision-relevant evidence or
+preview. Use a short option that points elsewhere only to select among sections
+or work items that already exist independently of the decision; do not create
+separate sections to hold an ask's alternatives. Allow multiple picks only when
+several options may stand.
 
 On the page the group's last cell is an option the reader writes, saying
 `Another option`, so author the alternatives you actually mean and no catch-all

skills/leaf/references/authoring-revisions.md

@@ -50,9 +50,10 @@ Each active revision presents what is live now. Remove a concluded run or
 superseded section instead of adding the next one beside it. Keep older material
 only when the current work still needs its context; move only the needed
 passages to a `Past work` section at the foot, inside a collapsed `<details>`
-whose summary names what it contains. Preserve the ids and words of passages
-that survive. Mark a concluded `lf-options` group `settled` when it retires
-inside a section that remains live.
+whose summary names what it contains. A passage whose id anchors an open thread
+or holds a standing decision survives with its id and words whatever else goes;
+`version check` refuses a version that drops one. Mark a concluded `lf-options`
+group `settled` when it retires inside a section that remains live.
 
 Relocation is not revision: moving unchanged content needs neither a suggestion
 nor `restated`. Keep a decision live while it is being applied, and settle it

skills/leaf/references/page-authoring.md

@@ -102,9 +102,10 @@ title and lede before it, and put the current workstream first: ordering makes i
 the default for a reader with no saved panel or reading position. Remove earlier
 runs when the current work no longer depends on them. If their context is still
 needed, keep only that context in a collapsed `<details>` inside the relevant
-tab. A saved panel or restored position takes precedence. Threads, asks,
-versions, and sign-off still cover the whole page, so none of that runtime chrome
-belongs inside a tab.
+tab, and keep with it any passage whose id anchors an open thread or holds a
+standing decision. A saved panel or restored position takes precedence. Threads,
+asks, versions, and sign-off still cover the whole page, so none of that runtime
+chrome belongs inside a tab.
 
 ## Reading cost
 

tests/test_render_export.py

@@ -146,7 +146,9 @@ def test_the_example_preview_command_exports_a_file_that_opens_on_its_own(
     errors = watched(page)
     page.on("requestfailed", lambda request: errors.append(f"unfetched {request.url}"))
     page.goto(out.as_uri(), wait_until="load")
-    expect(page.get_by_role("heading", name="Per-token rate limits")).to_be_visible()
+    expect(
+        page.get_by_role("heading", name="Unified diff in the switch picker")
+    ).to_be_visible()
     assert page.locator("script").count() == 0
     assert page.locator('link[rel="stylesheet"]').count() == 0
     assert page.locator("style").count() > 0

tests/test_site.py

@@ -283,7 +283,7 @@ def test_an_example_paints_while_every_stage_of_site_startup_is_held(
     try:
         with page.expect_request("**/leaf.js"):
             page.goto(example_url(hosted, "pr-walkthrough"), wait_until="commit")
-        expect(page.locator("h1")).to_have_text("Per-token rate limits")
+        expect(page.locator("h1")).to_have_text("Unified diff in the switch picker")
         expect(page.locator("h1")).to_be_visible()
 
         assert boot, "the positive control did not hold the site boot module"